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>)

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

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

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.

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,

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

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

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.

I think one of the reasons Alex is getting pushback is that everybody
knows this is a horrible can of worms--Joseph referred to "relitigation"
--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.

If it is, what is to be done?

Regards,
Branden

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