Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]

Hi Steve,

> Date: 2026-08-02 09:45:17-0400
> From: Steve Summit <scs@eskimo.com>
>
> Alejandro wrote:
> >> Certainly, today, strncpy and strncat are the new gets.
> >
> > This is deeply incorrect.
> 
> That was a side point, but to clarify what I meant:
> 
> Once upon a time (and still today), it's a reasonable thing to say:
> 
> 	Never use gets.  Don't worry if you don't understand the
> 	issue, don't worry if you heard someone say there's an
> 	obscure circumstance under which it might be useful,
> 	just don't ever use it; pretend it doesn't exist.
> 
> Today I think it's equally reasonable to say:
> 
> 	Never use strncpy and strncat.  Don't worry if you don't
> 	understand the issue, don't worry if you heard someone
> 	say there's an obscure circumstance under which they
> 	might be useful, just don't ever use them; pretend they
> 	don't exist.

This is not equally reasonable.  First of all, because there really is
an obscure circumstance under which, not only they are useful, but
actuall they are the best tool for the job.  If you tell users to never
ever use them, you're treating users as childs uncapable of
understanding the facts.  In fact, the documentation should instead
document the facts in a way that programmers can understand them and use
them appropriately.

Secondly, because this somehow attributes the danger to specific
functions, but the danger is in misusing functions.  For example, N2349,
which standardized memccpy(3), was following this premise: strncpy(3)
and strncat(3) are bad, so let's just find anything else; as long as
it's not one of those two functions, it should be fine.  But because
the underlying problem is not --and never has been-- the tools, but the
humans that misuse them, we have the irony that memccpy(3) is as
dangerous as strncpy(3), and even the paper that proposed it for
standardization invokes UB in the example code that is supposed to show
how it can be used for string copying.

> Though perhaps not strictly true, this is good advice, because it
> will never lead the average programmer astray.

No, it's not good advice either.  memccpy(3) and N2349 is a
counter-example of how even an expert programmer (Martin Sebor) will
still be led astray.

> strncpy is not a "fine function", because nobody is using
> (or should be using) fixed-width string buffers any more.
> (See, I can be opinionated, too! :-) )

I do use it in new code still today in shadow-utils.  I've heard tar(1)
also needs that, and a few other places.  Admittedly, that's orders of
magnitude less than strings.

> But we don't need to argue about this.  I said "strncpy and
> strncat are the new gets" to concede a point, to agree that
> discouraging the use of formerly-acceptable interfaces --
> a point that I thought you, and certainly that various people,
> were trying to make --

Not exactly; my point is that education must be used to teach users how
to correctly use interfaces.  I consider all these interfaces perfectly
acceptable.


Cheers,
Alex

> might be reasonable, even though it's one
> I often find myself disagreeing with.  But that's an opinion I
> decided to leave out of my previous message, and I'm not going to
> go down that road here, either.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]