Re: [ACPI] Re: [PATCH] bad strlcpy conversion breaks toshiba_acpi

[Matthew Wilcox <willy@debian.org>]

On Fri, Jul 25, 2003 at 06:57:09PM +0200, Andries Brouwer wrote:
> strlcpy is for strings, not for character arrays.
> The *BSD version accesses the source past the size-1 characters that are copied:
> 	while (*s++)
> 		;
> Thus, replacing strncpy (used to copy character arrays, possibly not 0-terminated)
> by strlcpy is wrong.

But using strncpy() is _also_ wrong because of its NUL-padding behaviour.
There's really four different situations and strncpy is only suitable
for one of them:

a) Copy at most n bytes of a string to another string (strlcpy)
b) Copy at most n bytes from a character array into a string (strncat?)
c) Copy at most n bytes from a string to a character array that will
   be returned to user space (strncpy)
d) Copy n bytes from one character array to another (memcpy)

stpcpy is another interesting variant on the awful strcpy, but we'd need
a stpncpy too.  strncat is a little dubious for case (b) since you need
to initialise the dest with a NUL in the first byte.

C's string handling sucks, and everybody knows it.  Making strings a first
class object may be a cure worse than the disease (for the intended use
of C; for scripting languages it makes perfect sense).

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk