The dangers of static buffers in rsync code
Wayne Davison
wayned at samba.org
Tue Dec 30 13:19:28 EST 2003
On Mon, Dec 29, 2003 at 04:55:19PM -0500, Cristian Gafton wrote:
> I have been trying for quite a while now to understand why is the
> flist.c:f_name() function implemented using static buffers. Anyone
> care to comment?
It's fairly handy for short-lived stuff, such as a printf() statement
that need two f_name() values. However, as you noted, for long-lived
stuff, it is an accident waiting to happen.
> This is bad and needs some fixing... Little hammer or big hammer?
I'm inclined to go with the big hammer for the next release (after
2.6.0). The f_name() function is labeled as one of the biggest hot
spots in the code, so optimizing it to allow an expansion into a
local buffer should make it both safer and faster (one section of the
code currently uses strdup() to protect the f_name() value -- ick).
Also, optimizing the string-compare case to avoid copying would
probably be a win as well. I've got some code that takes a stab at
doing this:
http://www.blorf.net/rsync-big-hammer.patch
It's been only minimally tested, so use it either as an indicator of
what I'm currently considering for post-2.6.0, or feel free to help
test it.
..wayne..
More information about the rsync
mailing list