Subject: Re: gzip buffer overflow found
To: Brian Grayson (home) <bgrayson@austin.rr.com>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 01/24/2001 13:50:38
[ On Sunday, January 21, 2001 at 17:18:00 (-0600), Brian Grayson (home) wrote: ]
> Subject: Re: gzip buffer overflow found
>
>   I just tested this out, and yes, strncpy goes forever adding 0's,
> while strlcpy does the minimum memory traffic needed.

The "original" implementation in V7 loops from 0 to `n', explicitly
stating in the comment at its top that it will "Copy s2 to s1,
truncating or null[sic]-padding to always copy n bytes."  I don't know
what the motivation for this was, but it's obviously been that way for a
very long time.

These days I'm pretty sure it's still mandated by the ISO C standard.  I
don't have a copy of the standard, but each of K&R (2nd edition),
Harbison&Steele, and the 4BSD manual pages (which claim ANSI X3.159-1989
conformance for strcpy() and strncpy()) explicitly state that strncpy
always copies `n' characters to the destination, padding with '\0' chars
if the source was less than `n' characters (and of course not
terminating the destination at all if the source is longer than `n'
characters).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>