Messages in this thread | | | Date | Sun, 27 Jul 2003 22:02:03 +0100 | From | Matthew Wilcox <> | Subject | Re: [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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |