Rendered at 13:15:18 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
wpollock 17 hours ago [-]
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.
bitwize 10 hours ago [-]
Should be using strcpy_s or strncpy_s.
spwa4 11 minutes ago [-]
It would have been so much funnier if they let Claude Mythos do it, commenting it would have a much harder job from now on.
How does strv2cstr work? I assume it doesn't allocate, so not sure how it can add a null terminator.
uecker 17 hours ago [-]
It will not add one if there isn't one already. (I should probably rename this function, work in progress..). But the type is an array of the correct length.
Edit: renamed to strv2array
whytevuhuni 17 hours ago [-]
Ah, okay. In that case I feel like the only sane way to approach this is to completely abolish null-terminated strings, and reimplement everything (including stuff like printf's format and arguments) in terms of strv. Otherwise if there has to be a 2cstr function, it should be an allocating one.
uecker 17 hours ago [-]
Reimplementing everything is not an option in C. But one should be able to pass string views directly to printf.
The allocating version is what string_dup does. strv2cstr is certainly more dangerous. But as since the size is encoded in the return type, compilers can add bounds checking (and partially already do so).
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".
NackerHughes 10 hours ago [-]
string.h
parasti 7 hours ago [-]
It's a header file not a library.
Joker_vD 2 hours ago [-]
It's not a header file, it's just a header, strictly speaking: the standard explicitly allows it to not be an actual file, and indeed there are implementations that don't have standard headers available as actual on-disk files. And, also strictly speaking, it should be <string.h>. You know, if we're being pedantic.
parasti 57 minutes ago [-]
My point isn't about that, though. My point is if you start a blog post with "The C string library", my confidence in your ability to discuss the topic is shot before I even finish reading the sentence.
Joker_vD 43 minutes ago [-]
And my point is that if you start nitpicking a perfectly understandable (if slightly imprecise) and widely-used terminology, you better not open yourself to the self-same criticism lest people would justifiably ignore your opinion.
After all, what C has is "the C library". It's what standard literally calls it (it doesn't even explicitly provide for existence of other kinds of libraries) but everyone calls it "the standard library". Is it correct? Arguably, no.
benj111 5 hours ago [-]
Define library. Surely a library is a collection of functions, not a collection of files, so you could have a single file library. I don't know at what size a collection of functions becomes a library, but I don't think anyone does.
Ultimately this file is supposed to be the one stop shop for all string related needs, so in what sense isn't that a library.
AlienRobot 2 hours ago [-]
I think they mean it's part of the standard library, instead of being a separate library.
rho138 17 hours ago [-]
When a wordpress site has more ads than arstechnica.
happymellon 6 hours ago [-]
Arstechnica has ads?
gblargg 6 hours ago [-]
Someone here browses without an ad blocker?
okl 17 hours ago [-]
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).
> It can read past the end of the src-buffer, when sizeof src < sizeof dest and src is not nul-terminated.
So basically, don't invoke a function "strscpy — Copy a C-string into a sized buffer" on something that is not a C-string. Its description specifically states that it copies a string into a buffer. Compare with the wordings in standard of strcpy ("The strcpy function copies the string pointed to by s2 (including the terminating null character) into the array pointed to by s1") and strncpy ("The strncpy function copies not more than n characters (characters that follow a null character are not copied) from the array pointed to by s2 to the array pointed to by s1... If the array pointed to by s2 is a string that is shorter than n characters...").
It's not a function to copy an array into an array (there is memcpy/memmov for that); it's a function to copy a string into an array which, after the function is finished, will certainly be a string (unless it's zero-sized, sigh).
rakel_rakel 17 hours ago [-]
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!
jmclnx 18 hours ago [-]
As I expected, this is about removing strncpy() from the Linux Kernel, not glib.
Removing strncpy() from glib would be awful for applications :)
Edit. Meant glibc, thanks mattst88
mattst88 18 hours ago [-]
I suspect you mean glibc.
verandaguy 14 hours ago [-]
GP may have been commenting that they don't find this development particularly glib.
79a6ed87 18 hours ago [-]
Confusion comes from Linux being used as a replacement term for any distro
The C standard library doesn't have strscpy or the others; it still has strncpy.
The tests are maybe better examples than those on godbolt. https://codeberg.org/uecker/noplate/src/branch/main/tests/st...
Edit: renamed to strv2array
The allocating version is what string_dup does. strv2cstr is certainly more dangerous. But as since the size is encoded in the return type, compilers can add bounds checking (and partially already do so).
After all, what C has is "the C library". It's what standard literally calls it (it doesn't even explicitly provide for existence of other kinds of libraries) but everyone calls it "the standard library". Is it correct? Arguably, no.
Ultimately this file is supposed to be the one stop shop for all string related needs, so in what sense isn't that a library.
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...
So basically, don't invoke a function "strscpy — Copy a C-string into a sized buffer" on something that is not a C-string. Its description specifically states that it copies a string into a buffer. Compare with the wordings in standard of strcpy ("The strcpy function copies the string pointed to by s2 (including the terminating null character) into the array pointed to by s1") and strncpy ("The strncpy function copies not more than n characters (characters that follow a null character are not copied) from the array pointed to by s2 to the array pointed to by s1... If the array pointed to by s2 is a string that is shorter than n characters...").
It's not a function to copy an array into an array (there is memcpy/memmov for that); it's a function to copy a string into an array which, after the function is finished, will certainly be a string (unless it's zero-sized, sigh).
Removing strncpy() from glib would be awful for applications :)
Edit. Meant glibc, thanks mattst88