Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar <alx@kernel.org>]

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

Hi Sam,

> Date: 2026-07-31 22:59:47+0100
> From: Sam James <sam@gentoo.org>
>
> (*) Alex has a history of making opinonated changes like this to
> man-pages, such as removing references to older standards, and using a
> somewhat novel (to many) syntax for prototypes.

I think this comment deserves a well thought response.

"Opinionated" is your subjective knee-jerk way of saying it.  I don't
agree with it.

I'd say I have a history of making changes based on thorough revision of
history and technical merits, even when that research is contrary to
decades (or half-centuries) of common practice, and possibly to
current or withdrawn standards.

In this case, and I don't mean this specific patch set, but the years-
long revision of string documentation that I've been carrying out, we
have a conflict between the design and correct use of string and memory
functions, and their common use today.

The functions that are most subject to this conflict are strncpy(3),
strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
affected, and the rest of mem*() minorly affected.

They were originally designed for a specific use case for which they
were great.  This knowledge has been lost in time, and I've been working
to recover that knowledge.

Precisely because of standards and other documentation that isn't
written with the level of care that I have, we have decades of misuses
of strncpy(3) and strncat(3).

Moreover, it's in other places that you should be complaining about.
GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
which we could very well call opinionated, and I haven't seen anyone
reporting them as bogus before I did.  Those diagnostics have not been
considered opinionated, just because they follow mainstream (bogus)
usage of these functions, but they are indeed forcing an opinion of how
these functions should be used over other uses that may be more uncommon
but which are actually the original and correct uses of these functions.
<https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>

It's curious that you called the GCC diagnostic "heuristics" instead of
"opinionated".  There's nothing about heuristics there.  It's just an
enforcement of an (incorrect) opinion about how these functions should
be used.

And since C23, we're seeing that the same story is repeating with
memccpy(3), which was once a niche function that was great for
implementing fgets(3), and now is misused by everyone and their dog for
copying strings with truncation.

I have spent probably more time than anyone in the last 5 years
researching about string handling, and have proven the correctness of my
research in the shadow-utils project, where most of my work has been in
revising string and memory handling code.  I've fixed uncountable subtle
bugs in such code, and have made the resulting code actually readable.
And the number of accidental regressions is minimal (IIRC, one or two
regressions related to string and memory handling, in all that time, and
not too dangerous).

Thus, I think it is my responsibility, as maintainer of the
documentation project most read by C programmers, to let our audience
learn what I've learnt in these years, and allow them to write safe
string- and memory-handling code.

It is thanks to this years-long research that I've been able to gather
important knowledge from people like Mark Harris, Doug McIlroy, Branden,
and many others, who hold knowledge that few other programmers possess,
and spread it to the world.

I'd consider it a negligence to do the easy thing and follow what
standards say, or what most programmers do, because that's what has led
us to the well-known mistakes that C programmers make.

FWIW, regarding the possible conflict of interest that was mentioned
yesterday, I'll say that I don't get paid for my contributions to ISO C
as a member of WG14.  There's no benefit to me other than public
recognition.  I'll also disclose the exact quantity that I've been paid
for maintaining the Linux man-pages project:

	110 kUSD in 2025 (from 5 sponsors)
	75 kUSD in 2026 (from 3 sponsors)

I'm convinced that that doesn't have any effects in my decisions here,
as I've had a consistent record of decisions well before I had any
economic benefits from maintaining this project.  None of those sponsors
have expressed any interest in favour of these decisions (nor against).

I'll rumiate a bit more on these patches, and probably make minor
changes to them, but the essence of documenting <memory.h> for all of
mem*() and strn*() in SYNOPSIS is most likely to be eventually merged.
I'll be careful to document what the standards say in a way that isn't
confusing to users, and also in general will try to document it in a way
that is positive for our audience --even if some of that audience may
have knee-jerk reactions, like you are having at the moment--.  I have
also received very positive feedback for other changes for which some
people have noisily had knee-jerk reactions.  I believe it is my duty
as maintainer of this project to do this change.


Have a lovely day!
Alex

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

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