alt.hn

6/26/2026 at 6:19:39 AM

Linux Kills Strncpy

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

by ingve

6/28/2026 at 8:17:45 PM

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.

by wpollock

6/28/2026 at 7:52:39 PM

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

by uecker

6/28/2026 at 8:11:03 PM

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

by whytevuhuni

6/28/2026 at 8:16:30 PM

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

by uecker

6/28/2026 at 8:31:29 PM

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.

by whytevuhuni

6/28/2026 at 8:38:19 PM

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

by uecker

6/28/2026 at 7:30:29 PM

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

by tom_

6/28/2026 at 8:20:08 PM

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

by parasti

6/28/2026 at 8:05:25 PM

When a wordpress site has more ads than arstechnica.

by rho138

6/28/2026 at 8:05:47 PM

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!

by rakel_rakel

6/28/2026 at 8:17:09 PM

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

by okl

6/28/2026 at 7:21:23 PM

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

by jmclnx

6/28/2026 at 7:34:44 PM

I suspect you mean glibc.