Linux 7.2 removes strncpy API

Linux 7.2 has officially removed the strncpy API from the Linux kernel. This concludes a six-year migration effort involving approximately 362 commits to eliminate all remaining internal users of the function.

Why strncpy was removed

The strncpy function was identified as a persistent source of bugs and performance degradation within the kernel due to two primary flaws:

  1. Counter-intuitive Semantics: The function's behavior regarding NUL termination is often misunderstood, leading to potential memory safety issues. Specifically, if the source string is longer than or equal to the specified size, strncpy does not NUL-terminate the destination string.
  2. Performance Overhead: The function performs redundant zero-filling of the destination buffer if the source string is shorter than the specified size, which wastes CPU cycles.

As noted by Walter Bright, a veteran C developer, the presence of strncpy in a codebase is often a primary indicator of potential bugs during code reviews.

Recommended replacements in Linux kernel code

Because strncpy served several different (and often conflicting) purposes, the Linux kernel has replaced it with a suite of more explicit functions. Developers must now choose the replacement based on the specific requirements of the memory operation:

  • strscpy(): Used for destinations that must be NUL-terminated.
  • strscpy_pad(): Used for NUL-terminated destinations that specifically require zero-padding.
  • strtomem_pad(): Used for fixed-width fields that are not NUL-terminated. This function is specifically designed to signal the conversion of a C-string into a fixed-width legacy memory field and utilizes the __nonstring attribute to avoid bugs related to sizeof(dest).
  • memcpy_and_pad(): Used for bounded copies that require explicit padding.
  • memcpy(): Used for memory copies where the length is already known.

Engineering context and community insights

A long-term systems engineering effort

The removal of strncpy is viewed by the community as a prime example of the "boring grind" of systems engineering. Unlike the addition of new features, the removal of a legacy API across a massive codebase requires a methodical, multi-year approach to ensure stability while maintaining functionality.

Historical context of the API

Industry veterans point out that strncpy was originally designed for a very specific use case in early UNIX: copying filenames to directory entries that consisted of a 2-byte inode number and a 14-byte zero-padded, non-terminated name field. Using it as a general-purpose string copy function was a fundamental misuse of the API that persisted for decades.

Broader C language critiques

The discussion around this removal highlights ongoing frustrations with the C language's handling of strings. Community members noted that the lack of a native string type—such as fat pointers, slices, or string views—forces developers to rely on these complex, error-prone manual memory management functions. Some contributors suggested that the adoption of Pascal-style strings or a struct containing a pointer and length (similar to std::string in C++) would have prevented these issues entirely.

Sources