Live data from Hacker News

6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

smist08.wordpress.com

31–40 of 42 posts

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#31
post #30

Earlier quoted context omitted.

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.

So you merely discard others' opinions merely on the fact of them using speech patterns that are not even incorrect, you just personally dislike them? Okay, that's fine, I guess, although you initially explicitly framed it as a correctness problem: "There is no "C string library".

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#32
post #19

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.

Should be using strcpy_s or strncpy_s.

> Should be using strcpy_s or strncpy_s

These functions are optional in the C standard and not always present. AFAIK, they are not included in glibc as of 2025.

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#34
post #14

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".

It is not only not mportant at all, but also not real concern

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#35
post #19

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.

Should be using strcpy_s or strncpy_s.

Annex K (which is what that is) is sufficiently unpopular as to have been under discussion to be removed from the standard. Few implementations exist, and even fewer conform to the standard (e.g. Microsoft's doesn't).

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

Furthermore, since the kernel uses no C library, it's the kernel developer's choices what to implement and use.

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#36
post #35
post #19

Earlier quoted context omitted.

Should be using strcpy_s or strncpy_s.

Annex K (which is what that is) is sufficiently unpopular as to have been under discussion to be removed from the standard. Few implementations exist, and even fewer conform to the standard (e.g. Microsoft's doesn't). https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm Furthermore, since the kernel uses no C library, it's the kernel developer's choices what to implement and use.

Isn't Microsoft the same group that still won't allow you to write "import " in C++ ?

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#37
No mention of strlcpy (which was the safe replacement for strncpy in the stdlib about 15 years ago when I first heard of the former).

Apparently strscpy handles un-terminated input strings a bit better than strlcpy, but not scanning past the given length.

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#39
post #35

Earlier quoted context omitted.

Annex K (which is what that is) is sufficiently unpopular as to have been under discussion to be removed from the standard. Few implementations exist, and even fewer conform to the standard (e.g. Microsoft's doesn't). https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm Furthermore, since the kernel uses no C library, it's the kernel developer's choices what to implement and use.

Isn't Microsoft the same group that still won't allow you to write "import " in C++ ?

VC++ has the only actually usable header units implementation across C++ compilers.

Re: 6 years and 360 patches to clean all instances of strnpy out of the Linux kernel

#40
> Back in 1972, the goal was to be as fast and efficient as possible. Hackers weren’t a concern since computers weren’t connected.

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.

Post reply on HN