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

--v3jqe5dmj4tqp6bk
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: 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>)
MIME-Version: 1.0

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.
>=20
> 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

--v3jqe5dmj4tqp6bk
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpuTvIACgkQ0Z6cfXEm
bc50AA//T5Cudc4pXDRlczK1I0jhK8OjG/w23xhSujQF9gZOHWC8kMhIqTCbqrEo
ldKnzPu/kpccsrkVvx6Gt89aCVPFxtvgdlg4vhy3BNaiDWgS10pBHI26bRQ1Gx3n
fZDKTdmmiB0PIAOGXWImmD7AmNjxzuMjwBG/VVmEaTunyHF5EaK1A/ICTSlc+hZ9
5jzuAZDj10bsBAHpG93U0xJsXywQpwxNBViNYOskOzth8q97Hl0epT/UPESipu2x
K1+Sv0bTLMSCSlZ2yFtMdF12QVqjOhALLWyWekXYJRugjOy9HXNtEFRFeD5tmBgo
toHkC/mlyk2lsAdQBwsxM8HeazgKhg7yBDLfcE5Qfst/54DdEntQR2Y3E2u30S7F
kLu851KcE5gYYIoCBWPUEXj3MXvrD7qXPrPz6Rd7djqfGcIqVWOxYkBPUiCt0HfN
lzouOY2TtSvsPuQRq4SOR1n7cjfPFepbnc8X7WovN86reWx0i9CQR1oQPuV/f/6y
Fh5N6GJT1SVwAZ3gU7XVH0qKEert30CSziZAN18Ti4fcxejjuqBhkD7mwc/UNdvT
PVjva1YOW7fgJOvZ5UAYhZZ09lXkiJ7/icq/Z2Ytz9eSEQXOx78+GXP8UeepGzR4
p4lZb1D1XarzJ+MNHO1VkqfUQ1a49+3i4jiFkvAHNJE0rN5ZIPI=
=4bFx
-----END PGP SIGNATURE-----

--v3jqe5dmj4tqp6bk--