Linux finally deleted strncpy after six years and 360 patches, and a programmer who saw it born called it 50 years late
The kernel removed a C function that's been quietly producing bugs since the 1970s. In the thread, the man who first met strncpy half a century ago, and the creator of the D language, agreed on one thing: they always found a bug wherever it appeared.
strncpy was killed for 'counter-intuitive semantics' around NUL termination and wasteful zero-filling. The '360 patches' figure is 360 uses converted to safer calls, not 360 bugs.
The origin: it was written to copy 14-byte, zero-padded-but-not-terminated filenames out of early UNIX directory entries. It was never meant for strings.
What got removed and why
Phoronix reports that the Linux kernel has eliminated the strncpy API after roughly six years of work and 360 patches, landing in the 7.2 cycle. The reason, in the kernel's own words, is that strncpy has been a "persistent source of bugs… due to counter-intuitive semantics and behavior around NUL termination along with performance issues due to redundant zero-filling of the destination." One commenter corrected the headline's implied body count:
"Note that '360 Patches' is 360 uses of strncpy that have been removed, not necessarily bugs." — a commenter correcting the headline's implication
The function was a misunderstanding from birth
The best contribution in the thread was a piece of living history — why strncpy behaves so strangely is that it was never a string function at all:
"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." — a commenter recalling the original UNIX directory-entry use
That single fact explains the entire 360-patch saga: a routine designed to fill a fixed 14-byte field with padding was adopted for decades as if it safely copied strings, which it does not. The creator of the D language confirmed the pattern from the other end of the timeline:
"Whenever I've been asked to review C code, I always looked for strncpy and always found a bug with it." — Walter Bright, creator of the D programming language
The fix existed for 30 years and got blocked
The most pointed reversal noted that a safer replacement was available for a generation and kept out:
"A reminder that we've had strlcpy for ~ 30 years but it was never accepted into the Linux world because of typical petty open source bullshit." — a commenter on the strlcpy history
A 50-year-old bug, retired
This is what technical debt looks like at maximum maturity: a function born to pad fixed-width disk fields in the 1970s, mistaken for a string copy ever since, defended for decades against a safer alternative, and finally excised across 360 call sites over six years. Nobody will notice the deletion, which is the point — the payoff of removing a sharp tool is the absence of a future cut. The thread's two oldest voices, one who met strncpy 50 years ago and one who hunts it in code reviews, were unanimous: good riddance, and what took so long.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
He stored a whole web page inside a favicon. The thread had three older, cleaner ways to do it
The hack packs a page's HTML into a favicon's pixels, three bytes per pixel, and renders it from a tiny loader. It's charming. Then a security researcher pointed out you can drop the loader entirely with an HTML/PNG polyglot, and someone recalled deCSS hidden in a favicon back in 2000.