Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Alejandro Colomar <alx@kernel.org>]

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

Hi Branden, Doug,

> Date: 2026-08-01 14:54:35-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Doug,
> 
> At 2026-08-01T08:39:08-0400, Douglas McIlroy wrote:
> > Branden wrote
> > > I'm sure I don't need to bring to your attention what a mine field
> > > string/`char` sequence/memory buffer handling has been in C since
> > > the language's inception.
> > 
> > Yes, this is a property of the language, not a peculiar deficiency of
> > the <string.h> functions.

Actually, I'm going to disagree on the first principle: the language is
not flawed, and <string.h> functions aren't particularly bad either.

The fact that they can be used safely after you understand the tools
means that the tools are good.  It's the teaching that has been bad.

Just like with every sharp tool, you need to first understand the tool.

After 5 years of researching about <string.h> functions, I've proved
with example that one can rewrite vast amounts of string code without
regressions every two lines of code.  This can only mean that <string.h>
is not inherently dangerous, since I'm not especially free from the
human-mistake factor (actually, I feel I'm more prone to them than the
average programmer).

<string.h> lacks a few functions and macros that make life much simpler,
such as Linux's strscpy(9), gnulib's streq(3), and a few others.

That lack, I attribute it to the fact that programmers have been burnt
so many times on bad design that they have grown an aversion to adding
them.  The fiasco of Annex K has probably helped.

> I mostly agree.  I think it's possible that C's string interfaces
> managed to innovate some deficiencies of their own on top of those
> proferred by the underlying the language definition.  8-O
> 
> > As I see it, patching up perceived deficiencies of the functions adds
> > complexity to the language definition and to the task of code-reading,

I'm currently just proposing a documentation change (there's another
proposal I'm working on in parallel, which actually affects the
functions, but that's not what we're discussing now).  The functions are
virtually moved to a different header file, but nothing else changes.

That header file division will help with the teaching problem, which is
the problem that has affected <string.h> so badly for so long.

> That's true.  But it is also true that without clear guidance from the
> standard's specification of the library, and with the flagship text on
> the language having gone unrevised since 1988, those perceived
> deficiencies cause ad hoc innovations to sprout like mushrooms after a
> thunderstorm.  Some of those innovations, like OpenBSD's strlcat and
> strlcpy (1998), claw their way into acceptance.

And interestingly, OpenBSD's strlcpy/cat(3) suffer from DoS, which
Linux's strscpy(9) is free of.

> Others don't, and
> remain bespoke features of a particular code project--often with little
> commentary or accompanying documentation to illuminate them.

Indeed.

> The result?  Reading _any_ code that involves string/`char` sequence/
> memory buffer handling has a substantial complexity tax stuck onto it.

And indeed.

> Culturally, it used to be that any inadequacies of the C language or its
> standard library were hand-waved away because a coder of sufficient
> ability could bull through any challenge with cleverness.  Our community
> has been purged of that preening vanity ten thousand CVEs at a time.

And indeed.

> I think one of the reasons Alex is getting pushback is that everybody
> knows this is a horrible can of worms

I'd say they think they know.  I believe it's not a can of worms, if you
are strict about keeping it simple.

> --Joseph referred to "relitigation"

And because the C Committee has the bad habit of considering past
decisions of the committee as godspell, no matter how bad they prove to
be.  I've been repeatedly accused of relitigating realloc(p,0),
<string.h>, and many more bad decisions of ISO C.

One good news is that Microsoft is currently testing my proposed changes
to fix realloc(p,0), and when their testing is done, all the FUD that
we've been hearing that it can't be changed now because "it would break
the world" will just vanish.

> --and that in turn is because seasoned C practitioners have a shared
> dread that instead of a brilliant solution existing somewhere in library
> design space, we face only struggles over who the taxing authorities
> shall be.  And everybody hates the tax man.
> 
> > with little real benefit.
> 
> If there is no Pareto improvement available in any dimension, but just
> reshuffling of code-reading tax authorities, then you're right.
> 
> I can, at best, hope the situation is not that bad.

I am certain that the solution exists.

> If it is, what is to be done?


Have a lovely night!
Alex

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

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