[lkml]   [2003]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ACPI] Re: [PATCH] bad strlcpy conversion breaks toshiba_acpi
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean