Linux 7.2 Drops strncpy: What Dev Teams Must Do to Prepare
Hitesh Sondhi · September 8, 2026 · 5 min read
strncpy() has been a persistent source of bugs in the Linux kernel for years. After six years of work and over 360 patches, Linux 7.2 eliminates the strncpy API from the kernel tree entirely. Phoronix
If you're shipping C/C++ software that targets Linux, the kernel's decision is a signal about your own codebase. The same API contract problems that made strncpy a liability in the kernel apply to your userspace code.
Why strncpy Violates Its Own Contract
Its signature looks simple: char *strncpy(char *dest, const char *src, size_t n). You pass a destination buffer, a source string, and a size. What follows is where the contract breaks down.
When src is longer than n, strncpy copies exactly n bytes and does not null-terminate the destination. When src is shorter than n, strncpy fills the entire remaining buffer with null bytes. One case produces a buffer that isn't a valid C string. The other wastes CPU cycles writing zeros you don't need.
strscpy(), the kernel's replacement, always null-terminates the destination when the size is greater than zero. It doesn't pad. It returns the number of bytes copied or -E2BIG if the source was truncated. That return value gives you a contract you can actually check: detect truncation and handle it instead of silently shipping a corrupted string downstream.
What to Audit in Your Codebase
Kernel developers removed strncpy because it was a persistent source of bugs. Your userspace code has the same exposure.
Run a grep across your C and C++ source for strncpy(. Every call site is a candidate for migration. For each one, determine whether the code relies on the null-padding behavior. Some legacy code uses strncpy as a way to zero-fill a buffer after copying, which is a misuse but one that some programs depend on.
Replace each call with strscpy() if your target platform provides it. If strscpy isn't available, use snprintf() as a portable alternative: snprintf(dest, n, "%s", src). It null-terminates, doesn't pad, and returns the number of bytes that would have been written, so you can detect truncation the same way strscpy lets you.
Check the return value at every migrated call site. If strscpy returns -E2BIG or snprintf returns a value greater than or equal to your buffer size, the string was truncated. Your code needs to decide what happens next: log the truncation, reject the input, or expand the buffer. Silently continuing with a truncated string is how data corruption propagates through your system.
Don't replace strncpy with strcpy. That removes the size bound entirely and reintroduces the buffer overflow class of bugs that strncpy was supposed to prevent in the first place.
Your C/C++ components might be embedded in larger systems, like the on-device inference pipelines we build for on-device AI or voice AI clients. Buffer handling bugs in that context don't just crash. They corrupt data flowing into model preprocessing, producing silent failures that are expensive to trace.
Block strncpy in CI Before It Ships
Add a compile-time check. GCC and Clang both support -Wstringop-truncation, which warns when strncpy is used in a way that might not null-terminate the destination. Enable it in your CI build flags alongside -Werror for new code.
For existing code, start with -Wstringop-truncation as a warning rather than an error. Triage the output, fix the call sites, then promote to -Werror once the backlog is clear.
Set up a grep-based pre-commit hook or CI step that rejects new strncpy( calls. It's a blunt instrument, but it prevents regression. We use a similar pattern for banning deprecated APIs in our AI consulting work, and it catches mistakes before they reach code review.
If you're running static analysis with clang-tidy, enable the bugprone-strncpy-overload and security.insecureAPI.strncpy checks. These flag strncpy usage and suggest context-aware replacements.
Write a unit test that exercises the truncation path at each migrated call site. Feed a source string longer than your destination buffer and assert that the return value indicates truncation. Without this test, your migration from strncpy to strscpy might compile cleanly but still produce truncated strings that nobody catches until production.
The Kernel Migration Is a Lesson in API Design
Removing strncpy took six years and 360 patches because the function was deeply embedded across the kernel tree. Phoronix The lesson isn't just "stop using strncpy." API contracts with surprising behavior create a tax that compounds over time. Every caller has to know the quirks, and every new developer who assumes the function does what its name suggests introduces a bug.
When you design or choose APIs for your own systems, prefer functions whose return values tell you what happened. strscpy returns the copy length or an error. snprintf returns the would-be length. strncpy returns the destination pointer, which you already had. A return value that conveys new information is a contract worth building on. The kernel community spent six years paying down that tax. Any codebase that keeps calling strncpy accrues the same debt.
Sources:
