Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

--rea33jecakkmfr4z
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS:
 Document these as provided by <memory.h>)
MIME-Version: 1.0

At 2026-07-31T23:11:56+0000, Joseph Myers wrote:
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
> > > In other words, they were in that header for 6 years, and it's
> > > been implicitly obsolescent by virtue of the standard choice for
> > > the 37 years 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.
>=20
> When it's been obsolescent for 37 years, bringing back a header with
> the same name is just going to confuse people with 37 years of past
> information saying it's obsolescent (normally if one source says "use
> X" and another says "X is obsolescent", you can reliably assume that
> "X is obsolescent" is the more recent information, even without 37
> years of history involved).

Okay, well, <memory.h>'s out due to the above, and <mem.h> collides with
old, non-standard Borland and Watcom compilers (which live on still in
environments like FreeDOS[1]).

So how about <stdmem.h> or <stdmemory.h> for the standard mem*
functions?

> Any reasonable change there would involve a new header, say
> <strnpad.h> for strncpy and strncat, rather than resurrecting a very
> old one.

I agree with that.  As my previous email noted, I think C programmers
apply the mem* functions differently than they do str{n,}*.  I think
it's a good idea to erect a cordon sanitaire around the ever-troublesome
latter functions.

> > 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.
>=20
> It's inconsistent with how people have understood C ever since it was=20
> standardized.

This claim is a bit hand-wavy.  C has spent its entire lifetime being
notoriously poorly understood.  But especially in early days, the
compiler would spit out something anyway.  Hackers confused the
production of a linked object file with understanding the language.

C has single-handedly elevated "undefined behavior" into a field of
academic study.

> > It wouldn't be reasonable to move strn*() to <memory.h>, and then
> > leave mem*() in <string.h>, of course.
> >=20
> > Similarly, it wouldn't be reasonable to [move] strncpy/cat() to
> > <memory.h> and leave the rest of strn*() and all of mem*() in
> > <string.h>.
>=20
> On the contrary, it's only the functions for null-padded fixed-width
> buffers that are niche functions causing confusion, compared to all
> the rest of the functions in <string.h> for which it's a very
> well-established and well-understood location.  Some others like
> memccpy are *obscure*, but not confusing in the same way.

I agree with you here, but the base+bounds nature of the mem* functions
versus the null-terminated nature of the str[^n]* functions, warrants
separation.

37 years ago the C Committee seemed to feel it needed to economize on
standard header file names, so many unrelated interfaces got piled
together into .h files that consequently lacked coherence (in the
Yourdon/Constantine sense).

WG14 has been moving away from that notion for decades now.  A recent
example is <stdbit.h>.  Why not continue in that laudable direction?

I think

stdmem.h
string.h
stdstrn.h

would sharply separate concerns and promote clearer reasoning among
application developers.

Regards,
Branden

[1] https://www.freedos.org/books/cprogramming/part8/

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

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

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmptMJ0ACgkQ0Z6cfXEm
bc7ZCA/8DGmLo0gOr5GcFe6iRRqXRFwKBb6ZHN1vvIfmJ7DW/ZArV0zog2Fk2Kd/
rfMwbFLNdBptXDUX6O0TkKMvCmGwrUwL1riGqSVsREf/s0r3IYWsy88z7/Mo78KR
oHNhaTNfodUKA18D49ZS0pv98GwPfg0XK5RMOFyfhyyUwrwCFWGl1AGrX3sgYCm5
v92g1Ms0VZeIajq42qOlxSyAep2Fmo1cPBddgzdR9diU731piBHop7I5/8j+E+xM
siM8mPLvKBCeP8+d38g5N2rOKIut/KMg+Mxhpux0irM+Z8Yhtgdegyrai3VOCTlI
P1bPJ+8UGn2anyxoxkm6u24S9yt7XvtzYnDh3J1XfpxP17YYMQKb+TzWReMEt4oD
Y0mZ50YfjUGvC/PVqSK8GzcGv9vwmS5jgYNPRUrRU6PMWm5dg/FrgRM+k6eKB48k
DaL0QHFfK2+m4ipjqjpCFDpswQKWfAWhOA1kLfhXmYWYs1uBbFDNvhsF9pWdGocl
sYXLDu7ntFR4ecqcO3P6WqwY4lMgTclViTUCBIXX3r+bGm1fPIKRVmYupwpvCJc8
dJQV989+haxAYptR/VATcxqo/Q0c0F6iilAAC5T4EfahB7tYxrcZtxDap0/VOjsx
3lfYa+mr2CA/W1enhoyDEIThG1K02iZ8+qye37vdu8tP1YaJa58=
=6k72
-----END PGP SIGNATURE-----

--rea33jecakkmfr4z--