On Mon, Jan 19, 2004 at 02:39:56PM -0800, jw schultz wrote:
> If we are going to vet the path name for overflow (a good idea) lets
> do it once, explicitly, as we receive it instead of having tests
> scattered throughout the code.
Yeah, good idea.
> When all you are doing is concatinating a couple of strings snprintf
> is overkill
I forgot how slow snprintf() is (it's nearly three times slower than
other methods of concatenation). There are a few places in the code
that are already using it (such as the backup code), which we should
change in light of this.
A bigger problem, though, is that the current f_name_to() code doesn't
handle an overflow properly: if "bsize - off" is negative, the value
turns unsigned once it gets to the strlcpy() function. Ouch! Using
successive strlcat() calls would be safe, but using a strlcat() call
after a strlcpy() of just a couple hundred bytes has about a 50% speed
penalty compared to following it with an offset strlcpy() call.
I wrote a function that will let us concatenate values together safely
without a speed penalty. Encapsulating it in a function ensures that we
don't have to have a series of "if (no overflow) x = strlcpy(...);"
calls every time we concatenate something. It also ensures that we do
it the safe way everywhere.
The function is called with any number of character strings, like this:
total_len = stringjoin(dest, sizeof dest, s1, s2, s3, NULL);
I'll append my util.c patch to this email.
..wayne..
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
