Welcome to LWN.net

The following subscription-only content has been made available to you
by an LWN subscriber. Thousands of subscribers depend on LWN for the
best news from the Linux and free software communities. If you enjoy this
article, please consider subscribing to LWN. Thank you
for visiting LWN.net!

By Jonathan Corbet
October 26, 2023

The C programming language is replete with features that seemed like a good
idea at the time (and perhaps even were good ideas then) that have not aged
well. Most would likely agree that string handling, and the use of
NUL-terminated strings, is one of those. Kernel developers have, for
years, tried to improve the handling of strings in an attempt to slow the
flow of bugs and vulnerabilities that result from mistakes in that area.
Now there is an early discussion on the idea of moving away from
NUL-terminated strings in much of the kernel.

The biggest problem with NUL-terminated strings is that they carry no
information about the size of the buffer that contains them; that makes it
easy to create buffer overflows. Over the years, a number of APIs have
been created in an attempt to address this problem, adding functions like
strncpy(),
strlcpy(), and strscpy(), each of which is claimed
to be better than its predecessors. None of them change the core concept
of a NUL-terminated string, though, and none of them pleases everybody.

Over the years, the kernel has seen a long series of patches exchanging
calls from one set of string functions for another. Sometimes those
conversions have introduced bugs of their own, and maintainers have not
always been happy with this work. Recently, in response to a
patch converting strncpy() calls to strscpy() in the
NVMe driver subsystem, Christoph Hellwig questioned the
value of these changes:

We need to stop pretending that direct manipulation of
nul-terminated strings is a good idea. I suspect the churn of
replacing one helper with another, maybe