HN

Comments (80)

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

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

  mrlonglong
  the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.
• Menu

  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.
• D-Coder
  Note that "360 Patches" is 360 uses of strncpy that have been removed, not necessarily bugs.
• Menu

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

  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
• Menu

  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?
• Menu

  larodi
  Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.