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

--koztz5vqc63ea52w
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: Joseph Myers <[email protected]>
Cc: "G. Branden Robinson" <[email protected]>, 
	[email protected], Keith Bostic <[email protected]>, 
	Mark Harris <[email protected]>, Nevin Liber <[email protected]>, 
	JeanHeyd Meneide <[email protected]>, Christopher Bazley <[email protected]>, 
	"Serge E. Hallyn" <[email protected]>, Iker Pedrosa <[email protected]>, 
	"Evgeny Grin (Karlson2k)" <[email protected]>, Kees Cook <[email protected]>, bug-gnulib-mXXj517/[email protected], 
	libc-alpha-9JcytcrH/[email protected]
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>)
Message-ID: <am0lAEb1wuCJPDk7@devuan>
References: <[email protected]>
 <784288e704183a4297aeaa3d13af8edab18bc1ea.1785532392.git.alx-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
 <e1031c2c-37eb-3cee-8bf0-f3285803d4e3-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 <20260731215122.4p4aepsbgeoibx74@illithid>
 <89c9b877-54a8-6a7c-016d-51e4be210ad6-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 <am0fnb4BMRrTajqx@devuan>
 <0407bda3-c03a-93cb-9400-5fb8256a30f2-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
MIME-Version: 1.0
In-Reply-To: <0407bda3-c03a-93cb-9400-5fb8256a30f2-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi Joseph,

> Date: 2026-07-31 22:42:00+0000
> From: Joseph Myers <[email protected]>
>
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
>=20
> > > When an API has been in <string.h> since 1989, that means documenting=
=20
> > > <string.h> as the main location for that API - not some other locatio=
n one=20
> > > person thinks is better and that most of the community has never hear=
d of.
> >=20
> > FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
> > System V they go back further to 1983.
>=20
> In other words, they were in that header for 6 years, and it's been=20
> implicitly obsolescent by virtue of the standard choice for the 37 years=
=20
> since then.

Yes.  And I'm trying to revert the implicit obsolescence.  Obsolescence
isn't a one-way process.  Sometimes, evidence shows up, and the obsolete
feature must come back for $reasons.

FWIW, memccpy(3) was resurrected in C23 back from a cold death it had
been suffering since forever.  And that was less justified.

> Standards involve accepting agreed compromises that might not have been=
=20
> your first choice, rather than endlessly relitigating past disputes=20
> without new evidence or changed circumstances.  In this case, the choice=
=20
> of where to put the functions in C89 was an agreed compromise that=20
> implicitly obsoleted the previous location, and should have put an end to=
=20
> any arguments that <string.h> was a bad location for those functions in=
=20
> the absence of clear new evidence.

I agree that it wasn't necessarily obvious back then that the movement
to <string.h> was bad.  While I blame the C89 Committee for other stuff
they should have been aware of, this isn't one of them.

But now in 2026, we see that there have some been problems.

> We have plenty of clear evidence for=20
> confusion about strn*; we don't about mem*.

Thanks!  Now we have a common ground.

Indeed, while there might be a minimal problem with mem*() --the fact
of not starting by str makes them less misused--, the important problem
is strn*().

The solution of moving both mem*() and strn*() to <memory.h> and leaving
just str*() in <string.h> is a consistent one, because <string.h> then
remains strictly for string APIs, and <memory.h> is for the rest of byte
handling.

It wouldn't be reasonable to move strn*() to <memory.h>, and then leave
mem*() in <string.h>, of course.

Similarly, it wouldn't be reasonable to more strncpy/cat() to <memory.h>
and leave the rest of strn*() and all of mem*() in <string.h>.

This movement, while a bit massive, is consistent and self-explicative.
That is, the only reasonable way to move strncpy/cat() is to also move
strn*() and mem*().


Cheers,
Alex

>=20
> --=20
> Joseph S. Myers
> [email protected]
>=20

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

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

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

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmptJzEACgkQ64mZXMKQ
wqlLvxAAmcSHCM7L9Bf8M6n3wx7bPDNDi8YtOGtjnL+jy1Dmabp7FbN6WZ+tAjmM
7TKrAZqWO0H1PMZ1MLa7TnOpvsxbHgQ4vOR+jwcVyg514r9vwLC3O5zyTYMZDU0u
6vqBy/BPnQU6ZOz3LKSzFYb0h4GzupeehFJcHs+tCs2+siHXH04z3kG4jh4VKQ3M
Ru3ijwKb7a4FRopiiF1vkXGGrei8GKzsQFNc4wy5CVftf7NYim+6SysMf1geJY4J
eS0HCMnRELH4OlL3ZA3Pd/e4mJOCleo1SoFRSv+5JgFD5hwtxGvN4oYxOHjfT9s8
QNLZQQsWM/EGcOQZcnUdAPWOFWeNdvV1i7i0IqrNScsQbzji2u5c8eAIRYlW7XOn
Vvc0cCuCdGZUaG6U/jMw1Kp6aAgyDV7JqTXO3VUA1ABzpEGslyTP/Gr75NNWAAW5
eBxQ/gjvD7dMI8o3UcrFWJ6jI120tCEbJqXIB9FqRNbV7Bs8XQC+xN2lzrPuF+rU
Wcf3btjtrFj8+JTN/QFDrYP3STRd1VrQfqsg5P1njZnbA5X+Pds4/WXJqW3Mq84t
91Etg+zGeugkxZijjcY+1UjMIcwZilTUCQVnjPngr61gd9zoo3yZPh5ylhYELaSq
x9UDYQMUQrp+RMn8ieOTJpWipJfTpaJVQbwOF45UiTnzcNu0NnI=
=xtx7
-----END PGP SIGNATURE-----

--koztz5vqc63ea52w--