Re: on the irresponsibility of pursuing C language reform

Alejandro Colomar <[email protected]> Sun, 2 Aug 2026 01:24:28 +0200

Newsgroups	gmane.linux.man,gmane.comp.lib.gnulib.bugs,gmane.comp.lib.glibc.alpha
Message-ID	<am5_uA4MSujYCS9X@devuan>

Hi Keith,

> 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’s their job:
> > “Notice the include file is string.h. That’s an historic accident
> > maintained for compatibility reasons; don’t let that fool you, this
> > function doesn’t operate on strings.”
> 
[...]
> I should probably expand the NOTES a little bit, to be more clear about
> why we ignore the standard in the SYNOPSIS.

I've put that text in a centralized place, in the memory.h(3head) manual
page:

	$ MANWIDTH=64 diffman-git HEAD
	--- HEAD^:man/man3head/memory.h.3
	+++ HEAD:man/man3head/memory.h.3
	@@ -10,6 +10,11 @@ SYNOPSIS
	      #include <memory.h>
	 
	 DESCRIPTION
	+     These functions are also provided in <string.h>, as speci‐
	+     fied by ISO C.  This is a historic accident maintained for
	+     compatibility reasons.  Don’t let that fool you; these
	+     functions don’t necessarily operate on strings.
	+
	    Write
	      bzero(3)
	      memset(3)
	@@ -38,6 +43,19 @@ DESCRIPTION
	      memrchr(3)
	      memmem(3)
	 
	+STANDARDS
	+     BSD.
	+
	+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’t standardize this header file, and instead
	+     crammed all these functions in <string.h>, resulting in
	+     confusing programmers about the real purpose of these
	+     functions.
	+
	 SEE ALSO
	      string(3), string_copying(7)
	 

Cheers,
Alex

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

signature.asc (application/pgp-signature, 833 B)