When a wordpress site has more ads than arstechnica.
Arstechnica has ads?
6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
21–30 of 42 posts
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#22Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#23Earlier quoted context omitted.
string.h
It's a header file not a library.
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.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#24Earlier quoted context omitted.
It's a header file not a library.
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.
I think they mean it's part of the standard library, instead of being a separate library.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#25Earlier quoted context omitted.
string.h
It's a header file not a library.
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 . You know, if we're being pedantic.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#26strncpy 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 pa…
> It can read past the end of the src-buffer, when sizeof src 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).
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#27Earlier quoted context omitted.
It's a header file not a library.
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 . You know, if we're being pedantic.
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.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#28Earlier quoted context omitted.
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 . You know, if we're being pedantic.
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.
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.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#29It would have been so much funnier if they let Claude Mythos do it, commenting it would have a much harder job from now on.
Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel
#30Earlier quoted context omitted.
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.
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 st…
You're still falling back on "what the standard says". It's not a correctness question.