Not going with something already widely deployed (like strlcpy), which could also be used in userland (strscpy can't, it's return value in case of failure is out of scope) is exactly what I would expect from Linux.
You do you!
strncpy was originally used to write into fixed length buffers[1]. This becomes obvious when considering the padding behavior, as described in the C standard[2]: "If the array pointed to by s2 is a string that is shorter than n characters, null characters are appended to the copy in the array pointed to by s1, until n characters in all have been written."
strlcpy, often touted as a replacement, does not elicit the padding behavior but has another flaw: It is supposed to return the length of the string it tried to create, for example, so the user can call realloc without calling strlen again.[3] However, this final "strlen-tail" in strlcpy isn't bounded by the size parameter which describes dest, not src.
While strscpy is a marked improvement, there is still something to be careful about: It can read past the end of the src-buffer, when sizeof src < sizeof dest and src is not nul-terminated.[4] (Set the count argument to something like min(sizeof dest, sizeof src) to avoid that).
This article is a bit misleading. Linux kernel programming uses C, but not the C standard library and never has. The string functions discussed here are "helper" functions included in the kernel and are not part of the standard library.
The C standard library doesn't have strscpy or the others; it still has strncpy.
Starting with "The C string library" made me instantly tune out. C has a standard library, which has some string-related functions. There is no "C string library".
15 comments
[ 2.5 ms ] story [ 43.7 ms ] threadRemoving strncpy() from glib would be awful for applications :)
Edit. Meant glibc, thanks mattst88
The tests are maybe better examples than those on godbolt. https://codeberg.org/uecker/noplate/src/branch/main/tests/st...
strlcpy, often touted as a replacement, does not elicit the padding behavior but has another flaw: It is supposed to return the length of the string it tried to create, for example, so the user can call realloc without calling strlen again.[3] However, this final "strlen-tail" in strlcpy isn't bounded by the size parameter which describes dest, not src.
While strscpy is a marked improvement, there is still something to be careful about: It can read past the end of the src-buffer, when sizeof src < sizeof dest and src is not nul-terminated.[4] (Set the count argument to something like min(sizeof dest, sizeof src) to avoid that).
--
[1] - https://softwareengineering.stackexchange.com/a/438090
[2] - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf, 7.26.2.5 p. 3
[3] - https://manpages.debian.org/jessie/libbsd-dev/strlcpy.3.en.h...
[4] - https://manpages.debian.org/testing/linux-manual-4.8/strscpy...
The C standard library doesn't have strscpy or the others; it still has strncpy.
Apparently strscpy handles un-terminated input strings a bit better than strlcpy, but not scanning past the given length.
On the contrary, one of the reasons Multics got a higher security score than UNIX when analysed by DoD was caring about security with PL/I.
Also remember Sun's "The network is the computer", and the Morris worm in 1985 as UNIX started to be widespread across university campus.
Ah, and the failure to add fat pointers to C, as Dennis Ritchie proposal wasn't taken by WG14, nor improved upon.
C authors followed their own path with Alef, Limbo, and finally Go.