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