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

https://smist08.wordpress.com/2026/06/25/linux-kills-strncpy/

by ingve • 27 days ago

61 40 27 days ago

smist08.wordpress.com

jmclnx• 24 days 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

79a6ed87• 24 days ago

Confusion comes from Linux being used as a replacement term for any distro

mattst88• 24 days ago

I suspect you mean glibc.

verandaguy• 24 days ago

GP may have been commenting that they don't find this development particularly glib.

tom_• 24 days ago

Previously: https://news.ycombinator.com/item?id=48612943

uecker3• 24 days ago

BTW: I was experimenting a bit more with string and string view (strv) types in my e toy library: https://codeberg.org/uecker/noplate/

The tests are maybe better examples than those on godbolt. https://codeberg.org/uecker/noplate/src/branch/main/tests/st...

whytevuhuni2• 24 days ago

How does strv2cstr work? I assume it doesn't allocate, so not sure how it can add a null terminator.

uecker3• 24 days 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

rho1382• 24 days ago

When a wordpress site has more ads than arstechnica.

happymellon• 24 days ago

Arstechnica has ads?

gblargg• 24 days ago

Someone here browses without an ad blocker?

rakel_rakel• 24 days 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!

okl• 24 days 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).

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

Joker_vD4• 24 days ago

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

wpollock2• 24 days 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• 24 days ago

Should be using strcpy_s or strncpy_s.

wpollock2• 23 days ago

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.

eqvinox• 22 days ago

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.

parasti4• 24 days ago

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• 24 days ago

string.h

parasti4• 24 days ago

It's a header file not a library.

high_na_euv• 22 days ago

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

spwa4• 23 days 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.

effnorwood• 23 days ago

str | cp it's back. easy.

WhyNotHugo• 22 days ago

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.

pjmlp2• 21 days ago

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.

aftbit• 21 days ago

The HN title says `strnpy` instead of `strncpy` .....

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

Related Stories