strncpy is libc's most misleading function. Linux spent 6 years killing it

What happened

Linux 7.2 ships with zero remaining calls to `strncpy()` in the entire kernel tree. The merge that closed the last instance — commit `1a3746ccbb0a` — marks the end of a six-year cleanup led by Kees Cook and the Kernel Self-Protection Project. The total cost: roughly 360 patches, touching virtually every subsystem, each one reviewed and signed off by the maintainer who owned that code.

The headline number isn't 360 patches. It's that a function which has shipped in libc since 1979 was determined to be unsafe enough that the world's most-deployed kernel decided to remove every single use of it, by hand, with no automated rewrite. The kernel's own internal `strscpy()` is now the canonical replacement, alongside `memcpy()` for cases where the caller actually wanted a fixed-length blob, and direct struct-field assignments where the original `strncpy` was being used as a janky `memset`-then-copy combo.

The Phoronix write-up frames this as a milestone. The more interesting framing is that it took six years — not because the patches were hard individually, but because the semantics of every single call site had to be audited, since `strncpy` is doing at least three different things in different parts of the codebase.

Why it matters

Here is the dirty secret of `strncpy(dest, src, n)`: the `n` does not bound the copy in the way every C programmer's intuition says it does. `strncpy` is the only function in the C standard library that can return a non-null-terminated string, and it's also the only one that will silently zero-pad your destination buffer to the full length `n` even when `src` is much shorter. Both behaviors are footguns. Together they're a feature designed for the UNIX v7 directory-entry format — fixed 14-byte filename slots, no terminator — that has had no legitimate use case in mainstream code since the late 1980s.

Most programmers learn `strncpy` as "the safe version of `strcpy`." That is the most expensive misconception in C. Compare:

- `strcpy(dest, src)` — overruns if `src` is longer than `dest`. - `strncpy(dest, src, sizeof(dest))` — does not overrun, but leaves `dest` un-terminated if `src` is `>= sizeof(dest)`. Your next `strlen` call walks off into adjacent memory. - `strscpy(dest, src, sizeof(dest))` — what `strncpy` should have been: bounded, always null-terminated, returns either the copied length or `-E2BIG`.

The kernel's replacement function exists because no libc shipped one. `strlcpy` (OpenBSD's attempt) was rejected by glibc maintainers for over a decade on aesthetic grounds. `strscpy` was written for the kernel in 2015 and has since been ported into multiple userspace projects. Linux didn't just remove an unsafe function — it shipped a reference design for what the replacement should look like, then proved at scale that the migration is mechanically tractable.

The community reaction has been muted because the work was muted. There was no Hacker News thread when patch 47 of 360 landed in the SCSI driver layer. The same is true for patches 48, 49, and 50. That is what disciplined deprecation looks like: not a manifesto, but a years-long grind through subsystems most kernel hackers never touch. The 258-point HN thread on Phoronix's recap is people noticing only because the counter hit zero.

What this means for your stack

If you maintain a C or C++ codebase of any meaningful size, the practical lesson is not "go remove `strncpy`." It's the migration methodology. The kernel's playbook generalizes:

1. Identify the deprecated API and its replacement before you start. Don't ask call sites to figure out what they wanted. The kernel chose `strscpy` first, then went looking for `strncpy` calls. 2. Classify by semantic intent, not by syntactic match. Roughly a third of `strncpy` calls in the kernel were actually fixed-width field copies that wanted `memcpy`. Another third wanted real string copying. The remainder were genuinely buggy. A regex sweep with auto-rewrite would have shipped silent regressions in a third of the call sites. 3. Push reviews to the subsystem maintainer. Kees Cook didn't merge his own patches en masse. Each one went through the relevant subtree, which is why it took years — and why nothing broke. 4. Treat the deprecation as a build-time wall, not a documentation note. Once a subsystem was clean, future `strncpy` calls were caught by checkpatch and compiler warnings, not by hoping reviewers noticed.

Your codebase almost certainly contains the userspace equivalent: `sprintf`, `strcat`, `gets` (still, somehow), `atoi`, `system()` with shell-quoted strings. The kernel demonstrated that the cost of removing them is real but bounded — call it one full-time engineer-year per few hundred call sites — and the alternative is continuing to pay the bug-class tax indefinitely.

There's also a fresh angle for teams using LLM-assisted refactoring. The strncpy migration is, almost by accident, the best public dataset for what a careful semantic audit looks like across a huge C codebase. The 360 patches are public, paired with the original buggy code and the maintainer's review comments. If you're building or evaluating an agent that does API migrations, this is your gold-standard eval set.

Looking ahead

The next obvious target is `strcpy`. It's already rare in the kernel but not gone. After that: `sprintf` in favor of `scnprintf` (which actually returns the bytes written, not the bytes it would have written). Each one is its own multi-year project. The strncpy removal matters because it makes those projects look finishable instead of mythic — and because it ships a template that any sufficiently disciplined open-source community can copy.