Improving name-truncation detection

Wayne Davison wayned at
Tue Jan 20 01:44:20 GMT 2004

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.


More information about the rsync mailing list