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