proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform)
"G. Branden Robinson" <[email protected]> Sat, 1 Aug 2026 18:53:32 -0500
| Newsgroups | org.kernel.vger.linux-man |
|---|---|
| Message-ID | <20260801235332.vc443gozbqkqdqm5@illithid> |
--w772junpj4b3wbyx Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) MIME-Version: 1.0 Hi Alex, At 2026-08-02T01:24:28+0200, Alejandro Colomar wrote: > > Date: 2026-08-02 00:44:46+0200 > > From: Alejandro Colomar <[email protected]> > > > [...] > > > Advocating for better usage in the documentation is a different > > > thing, and a good thing. The man pages can even go pretty hard, > > > that=E2=80=99s their job: =E2=80=9CNotice the include file is string.= h. That=E2=80=99s an > > > historic accident maintained for compatibility reasons; don=E2=80=99t= let > > > that fool you, this function doesn=E2=80=99t operate on strings.=E2= =80=9D > >=20 > [...] > > I should probably expand the NOTES a little bit, to be more clear > > about why we ignore the standard in the SYNOPSIS. >=20 > I've put that text in a centralized place, in the memory.h(3head) > manual page: >=20 > $ MANWIDTH=3D64 diffman-git HEAD > --- HEAD^:man/man3head/memory.h.3 > +++ HEAD:man/man3head/memory.h.3 > @@ -10,6 +10,11 @@ SYNOPSIS > #include <memory.h> > =20 > DESCRIPTION > + These functions are also provided in <string.h>, as speci=E2=80=90 > + fied by ISO C. This is a historic accident maintained for > + compatibility reasons. Don=E2=80=99t let that fool you; these > + functions don=E2=80=99t necessarily operate on strings. > + That's a heavy editorial slant. I don't think it was a historical accident; it was a historical "on purpose"[1], with which you disagree. Here's a revision that goes a little less hard, favors active voice over passive, and is shorter. + ISO C mandates that <string.h> declare these functions. + Be aware that they do not necessarily operate on strings. > +STANDARDS > + BSD. If you're tracking SVID in the Linux man-pages project, I would guess that it was in the original SVID, which formalized/specified SVr2--but I can't find online any version of SVID older than its Fourth Edition. If you care about SVID, this point may bear further research. Matt G. of TUHS might have a line on older editions of SVID. > +HISTORY > + The <memory.h> header file is the original one which was > + added in System V (1983), and was later adopted by 4.3BSD > + (1986). It contained the original mem* functions. > + > + C89 didn=E2=80=99t standardize this header file, and instead > + crammed all these functions in <string.h>, resulting in > + confusing programmers about the real purpose of these > + functions. Again, you're going harder than you need to here. I propose: +HISTORY + System V (1983) introduced an initial set of mem* + functions in a <memory.h> file. 4.3BSD (1986) adopted + them. C89 specified them in <string.h>. + + The programmer bears the burden of selecting appropriate + functions for operations on memory buffers (which may + contain any bytes, including nulls) versus strings (which + null bytes terminate). If you like the foregoing, consider it: Signed-off-by: G. Branden Robinson <[email protected]> Regards, Branden [1] As one does with "all the glue", when one doesn't want a "major award" to be readily repaired... --w772junpj4b3wbyx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpuhvUACgkQ0Z6cfXEm bc7KbQ/8DCl6/657zY5rFy+cig8k13EpzQTQGIrAsPawN57sIuqH11eJqM+3U+tW gSaj/YerGZXCfrZRC+CBdEvxBRZVTLsnPxB4ngKLU/6B+aWGmQSco3uIPbJdraZp E47CUzJM3FwrYFvdQWotMa3okGrKz+QIguX/tXLRPU8f+zxIfQ7oowvG9l83xOCi Ow7exYXcbacNmQBK6l9zx9igZWSZKb7hQVyZEoUOM98KpR/oHVvkNajkkajLQ5MO Z3usDKscIo5MBJpdlcXvcvyc1tK5oha4Mkti3/2JXZg5iouBGOzeqzqG32PtwhAy Um68SvYXWrKtmevHV3Q2ZuDhde2GsbO3uclwRYuVQUr8xzWO/qVaSbNK7Elt3zOt e4cj9mtCgYtLKg65vt643YY4dnmkQQvBEgjQ+/0UfkfJVVU2xI00Yvx+TsouqJoj PC+2Zshk4i2tARCD68q53W9N+L/CwJHYnBQBy0+tYiMm+xzTqOu2ZelGj19GjqxH ukQZRjdVsRZNx6NqJ7WaQlSqUpMKcRVh+7QebGhtupUM1Qnrpgn5ycSInB6QR22V Bclxg1NbreSuuyORo3Dy33JFCgjtqBHBEVVlu6NBcGGrK09kufVcGZq+ZO5j/6ss HIBwh/MsJP6NNMIk6upiNmNd0Lv67MIiZhvzDX4w4XhMAYRujXU= =QVZk -----END PGP SIGNATURE----- --w772junpj4b3wbyx--