[CC trimmed]

Hi Branden,

> Date: 2026-08-02 02:27:44+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> > Date: 2026-08-01 18:53:32-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> >

[...]

> > If you like the foregoing, consider it:
> > 
> > Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com>
> 
> I'll probably modify it and note it as
> 
> 	Suggested-by: ...

The final memory.h(3head) manual page is here.  It contains a mix of
your text and Keith's text.

	memory.h(3head)                                 memory.h(3head)

	NAME
	     memory.h - memory operations

	LIBRARY
	     Standard C library (libc, -lc)

	SYNOPSIS
	     #include <memory.h>

	DESCRIPTION
	   Write
	     bzero(3)
	     memset(3)

	   Copy
	     memmove(3)
	     memcpy(3)
	     mempcpy(3)
	     memccpy(3)
	     strncpy(3)

	   Catenate
	     strncat(3)

	   Duplicate
	     strndup(3)
	     strndupa(3)

	   Compare
	     memcmp(3)
	     strncmp(3)
	     strncasecmp(3)

	   Search
	     memchr(3)
	     memrchr(3)
	     memmem(3)

	STANDARDS
	     BSD.

	     These functions are also provided in <string.h>, as speci‐
	     fied  by ISO C.  This is a historic mistake maintained for
	     compatibility reasons.  Don’t let  that  fool  you;  these
	     functions don’t necessarily operate on strings.

	HISTORY
	     SVr1, 4.3BSD.

	     System  V  (1983)  introduced an initial set of mem* func‐
	     tions in a <memory.h> header file.  4.3BSD (1986)  adopted
	     them.

	     C89 didn’t standardize this header file (without providing
	     any  motivation  or mentions in the documented rationale),
	     and instead crammed all these functions in <string.h>, re‐
	     sulting in confusing programmers about the real purpose of
	     these functions.

	     Most C libraries, including the  BSDs,  glibc,  and  musl,
	     provide <memory.h>.

	     Illumos  and  gnulib don’t provide it, though, and instead
	     use <string.h>.

	SEE ALSO
	     string(3), string_copying(7)

	Linux man‐pages 6.18‐18... 2026‐08‐03           memory.h(3head)

You can already get it through git, so if you want to make any specific
changes, please send a patch.

The specific pages (e.g., memcpy(3)) have also been updated.  I believe
the pages now reflect carefully both what the standard says, and the
more reasonable include, while also clearly pointing to this page where
the full story is detailed, for those who wonder, so that they don't
have to wonder and ask.

A sample here:

	SYNOPSIS
	     #include <memory.h>  // See STANDARDS

	     void *memcpy(size_t n;
			  void dest[restrict n], const void src[restrict n],
			  size_t n);

	STANDARDS
	     C11, POSIX.1‐2008.

	     ISO C and POSIX declare this function in  <string.h>;  see
	     memory.h(3head).

The commit message attributes the text to both of you.

	commit 44d6d3bbace4c5a459efb181bcd264b93a655698
	Author: Alejandro Colomar <alx@kernel.org>
	Date:   2026-08-02 01:20:46 +0200

	    man/man3head/memory.h.3: STANDARDS, HISTORY: Document some history about <string.h> and <memory.h>
	    
	    This text is an adaptation of text suggested by Keith and Branden.
	    
	    Suggested-by: Keith Bostic <keith@bostic.com>
	    Suggested-by: "G. Branden Robinson" <g.branden.robinson@gmail.com>
	    Cc: Sam James <sam@gentoo.org>
	    Cc: Joseph Myers <josmyers@redhat.com>
	    Cc: Mark Harris <mark.hsj@gmail.com>
	    Cc: Nevin Liber <nevin@cplusplusguy.com>
	    Cc: Collin Funk <collin.funk1@gmail.com>
	    Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>
	    Cc: Christopher Bazley <chris.bazley.wg14@gmail.com>
	    Cc: Bruno Haible <bruno@clisp.org>
	    Cc: Paul Eggert <eggert@cs.ucla.edu>
	    Cc: Serge Hallyn <serge@hallyn.com>
	    Cc: Iker Pedrosa <ipedrosa@redhat.com>
	    Cc: Evgeny Grin <k2k@drgrin.dev>
	    Cc: Kees Cook <keescook@chromium.org>
	    Cc: Steve Summit <scs@eskimo.com>
	    Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
	    Cc: Arsen Arsenović <arsen@aarsen.me>
	    Cc: bug-gnulib@gnu.org
	    Cc: libc-alpha@sourceware.org
	    Signed-off-by: Alejandro Colomar <alx@kernel.org>



Have a lovely night!
Alex

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