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>