the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.
larodi
Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.
PlunderBunny
I worked on a Win32 app that used space-padded strings, i.e. the destination string was padded with spaces, but there was still a null on the last byte. You had to use special versions of the string functions for length, copy etc. I’m not sure why this was - the source base was so old it might have had its origins in Pascal struct behaviour.
naturalmovement
A reminder that we've had strlcpy [1] for ~ 30 years but it was never accepted into the Linux world because of typical petty open source bullshit. This is why we can't have nice things. [1] https://man.openbsd.org/strlcpy
senfiaj
I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.
D-Coder
Note that "360 Patches" is 360 uses of strncpy that have been removed, not necessarily bugs.
lambdaone
This sort of boring grind is where the real work of systems engineering is done. Big infrastructure projects like this work on making the Linux kernel more reliable while still keeping it workable throughout the process move on the scale of decades, not months.
devsda
Did anybody else misunderstand the title as removing strncpy func for linux users ? For a moment, I misunderstood it as (g)libc removing strncpy and was worried about the trouble its going to cause.
WalterBright
"The strncpy function within the Linux kernel has been a "persistent source of bugs" for years due to counter-intuitive semantics and behavior around NUL termination along with performance issues due to redundant zero-filling of the destination." Huh. Whenever I've been asked to review C code, I always looked for strncpy and always found a bug with it.
qarl
Am I going to be the first person to ask this after five hours? Really? Wouldn't this work be extremely easy to implement with an LLM coder?
Animats
This is a job for Claude! What happens if you turn a job like that over to Claude Code? A mess? Good results? Code bloat? Worth trying on existing C programs.
jibal
The purpose of strncpy, which was originally part of the UNIX kernel code, was to copy file names to and from directory entries that consisted of a 2 byte inode number and a 14 byte zero-padded but not zero-terminated name field. I started warning my colleagues against using it the moment I saw it for the first time about 50 years ago.
twothreeone
wow, very humbling. I'm actually amazed how many people contributed to this. It's easy to get attribution for "cool new features", but arguable removing bad features is even more important for something as fundamental as the kernel. Cudos! I'm sure these are the sorts of things that will go down as folklore from the "founding ages", when everyone will have forgotten how to understand source code in 50 years and the Claude/Codex cruft just silently keeps piling on and burning the majority of our planets energy.
DerSaidin
strtomem_pad seems redundant with memcpy_and_pad, and also it requires the preprocessor: https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06... I was curious: Why have it, instead of just using memcpy_and_pad? AI's answer (paraphrased) was * Avoid possible bugs from manually write sizeof(dest) * Enforces the __nonstring Attribute * signals: "I am converting an actual C-string into a fixed-width legacy memory field." vs copy binary data & pad it. Interesting to learn about the __nonstring attribute: https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06... https://github.com/search?q=repo%3Atorvalds%2Flinux+__nonstr...
cm2187
A lot of pain and suffering to avoid having a string datatype.
Related Discussions
Found 5 related stories in 115.4ms across 11,093 title embeddings via pgvector HNSW
Discussion Highlights (15 comments)
mrlonglong
the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.
larodi
Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.
PlunderBunny
I worked on a Win32 app that used space-padded strings, i.e. the destination string was padded with spaces, but there was still a null on the last byte. You had to use special versions of the string functions for length, copy etc. I’m not sure why this was - the source base was so old it might have had its origins in Pascal struct behaviour.
naturalmovement
A reminder that we've had strlcpy [1] for ~ 30 years but it was never accepted into the Linux world because of typical petty open source bullshit. This is why we can't have nice things. [1] https://man.openbsd.org/strlcpy
senfiaj
I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.
D-Coder
Note that "360 Patches" is 360 uses of strncpy that have been removed, not necessarily bugs.
lambdaone
This sort of boring grind is where the real work of systems engineering is done. Big infrastructure projects like this work on making the Linux kernel more reliable while still keeping it workable throughout the process move on the scale of decades, not months.
devsda
Did anybody else misunderstand the title as removing strncpy func for linux users ? For a moment, I misunderstood it as (g)libc removing strncpy and was worried about the trouble its going to cause.
WalterBright
"The strncpy function within the Linux kernel has been a "persistent source of bugs" for years due to counter-intuitive semantics and behavior around NUL termination along with performance issues due to redundant zero-filling of the destination." Huh. Whenever I've been asked to review C code, I always looked for strncpy and always found a bug with it.
qarl
Am I going to be the first person to ask this after five hours? Really? Wouldn't this work be extremely easy to implement with an LLM coder?
Animats
This is a job for Claude! What happens if you turn a job like that over to Claude Code? A mess? Good results? Code bloat? Worth trying on existing C programs.
jibal
The purpose of strncpy, which was originally part of the UNIX kernel code, was to copy file names to and from directory entries that consisted of a 2 byte inode number and a 14 byte zero-padded but not zero-terminated name field. I started warning my colleagues against using it the moment I saw it for the first time about 50 years ago.
twothreeone
wow, very humbling. I'm actually amazed how many people contributed to this. It's easy to get attribution for "cool new features", but arguable removing bad features is even more important for something as fundamental as the kernel. Cudos! I'm sure these are the sorts of things that will go down as folklore from the "founding ages", when everyone will have forgotten how to understand source code in 50 years and the Claude/Codex cruft just silently keeps piling on and burning the majority of our planets energy.
DerSaidin
strtomem_pad seems redundant with memcpy_and_pad, and also it requires the preprocessor: https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06... I was curious: Why have it, instead of just using memcpy_and_pad? AI's answer (paraphrased) was * Avoid possible bugs from manually write sizeof(dest) * Enforces the __nonstring Attribute * signals: "I am converting an actual C-string into a fixed-width legacy memory field." vs copy binary data & pad it. Interesting to learn about the __nonstring attribute: https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06... https://github.com/search?q=repo%3Atorvalds%2Flinux+__nonstr...
cm2187
A lot of pain and suffering to avoid having a string datatype.