Hi Steve, > Date: 2026-08-02 08:52:04-0400 > From: Steve Summit <[email protected]> > [...] > Certainly, > today, strncpy and strncat are the new gets.
This is deeply incorrect.
gets(3) is a function that can't possibly be used safely.
strncpy(3) is a fine function for copying a string into a fixed-width
buffer. strncat(3) is a fine function for appending a
[[gnu::nonstring]] to a string. strncpy/cat(3) are bad when they are
misused, just like a screwdriver is bad for hammering nails.
gets(3) is not that.
This is something that even most of the people disagreeing to this
proposed change agree with.
> (As it happens,
> I've been spending real time just in the past few weeks coping
> with the fact that not every Linux C compiler I use ships with
> a glibc that supports strlcpy and strlcat.)
strlcpy/cat(3) have their own issues, although admittedly a DoS is
better than a buffer overflow.
Ideally, you should be looking for strscpy(9); but you should write it
yourself, because it's not provided by any libraries.
> But with that said, the place for those "interesting arguments"
> is not a man page! Man pages are supposed to be maximally
> pithy. Just the facts, ma'am.
"The facts" is more subjective than it seems at first glance.
Just some examples of manual pages before I touched them, to show that
I'm not even innovating. Maybe because I CC people I know disagree with
me, I get more vocal opposition, I guess.
Here's part of str[n]cpy(3) well before I got involved in the project.
DESCRIPTION
The strcpy() function copies the string pointed to by src,
including the terminating null byte ('\0'), to the buffer
pointed to by dest. The strings may not overlap, and the
destination string dest must be large enough to receive
the copy. Beware of buffer overruns! (See BUGS.)
The strncpy() function is similar, except that at most n
bytes of src are copied. Warning: If there is no null
byte among the first n bytes of src, the string placed in
dest will not be null‐terminated.
If the length of src is less than n, strncpy() writes ad‐
ditional null bytes to dest to ensure that a total of n
bytes are written.
A simple implementation of strncpy() might be:
char *
strncpy(char *dest, const char *src, size_t n)
{
size_t i;
for (i = 0; i < n && src[i] != '\0'; i++)
dest[i] = src[i];
for ( ; i < n; i++)
dest[i] = '\0';
return dest;
}
NOTES
Some programmers consider strncpy() to be inefficient and
error prone. If the programmer knows (i.e., includes code
to test!) that the size of dest is greater than the
length of src, then strcpy() can be used.
One valid (and intended) use of strncpy() is to copy a C
string to a fixed‐length buffer while ensuring both that
the buffer is not overflowed and that unused bytes in the
destination buffer are zeroed out (perhaps to prevent in‐
formation leaks if the buffer is to be written to media or
transmitted to another process via an interprocess commu‐
nication technique).
If there is no terminating null byte in the first n bytes
of src, strncpy() produces an unterminated string in dest.
If buf has length buflen, you can force termination using
something like the following:
if (buflen > 0) {
strncpy(buf, str, buflen - 1);
buf[buflen - 1]= '\0';
}
(Of course, the above technique ignores the fact that, if
src contains more than buflen - 1 bytes, information is
lost in the copying to dest.)
strlcpy()
Some systems (the BSDs, Solaris, and others) provide the
following function:
size_t strlcpy(char *dest, const char *src, size_t
size);
This function is similar to strncpy(), but it copies at
most size-1 bytes to dest, always adds a terminating null
byte, and does not pad the destination with (further) null
bytes. This function fixes some of the problems of str‐
cpy() and strncpy(), but the caller must still handle the
possibility of data loss if size is too small. The return
value of the function is the length of src, which allows
truncation to be easily detected: if the return value is
greater than or equal to size, truncation occurred. If
loss of data matters, the caller must either check the ar‐
guments before the call, or test the function return
value. strlcpy() is not present in glibc and is not stan‐
dardized by POSIX, but is available on Linux via the
libbsd library.
BUGS
If the destination string of a strcpy() is not large
enough, then anything might happen. Overflowing fixed‐
length string buffers is a favorite cracker technique for
taking complete control of the machine. Any time a pro‐
gram reads or copies data into a buffer, the program first
needs to check that there’s enough space. This may be un‐
necessary if you can show that overflow is impossible, but
be careful: programs can get changed over time, in ways
that may make the impossible possible.
You may have thought that the manual pages have never been opinionated
before, and that they were strict about containing facts. That's never
been true, though. You may or may not agree with the previous
non-facts, but that doesn't make them more valid.
> Finally, I really don't think that the the mapping between
> function x and header <y.h>, a mapping which I characterized as
> somewhat arbitrary, is something that the average programmer pays
> that much attention to. If strncpy or memset is to be found in
> a header called <string.h>, that doesn't tell us that these
> functions operate on strings,
That contradicts explicit claims by programmers in CC in this thread,
who have complained during code review (some months ago) that if
strncpy(3) is in <string.h>, then it must be because it's for copying
strings, and that I must thus be wrong rejecting code using it for
copying strings.
> any more than ssprintf appearing in
> <stdio.h> implies that ssprintf does I/O. So let's put the
> arguing, and the opinionating, and the educating, somewhere else,
> and have the man pages document (nay, recommend) precisely the
> headers that the Standard(s) say are standard.
Have a lovely day!
Alex
> Steve Summit
>
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
