[PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al.

[PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al.

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

Hi!

Here's a patch set for documenting mem*(3) and strn*(3) functions as
provided in <memory.h>.  This should put a stop to the misunderstanding
and misuse of these functions as handling strings; they handle bytes and
nonstrings (and in some cases, strings can be used as nonstrings or as
byte arrays, but very carefully).

This header is quite portable: {Free,Net,Open}BSD, glibc, and musl, at
least and since forever.

The C Committee is discussing standardization of <memory.h>, so let's
give it a bump.


Have a lovely night!
Alex


Alejandro Colomar (2):
  man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as
    provided by <memory.h>
  man/man*/{string.3,memory.h.3head}: Move functions to a new page
    memory.h(3head)

 man/man3/memccpy.3      |  5 ++-
 man/man3/memchr.3       |  5 ++-
 man/man3/memcmp.3       |  5 ++-
 man/man3/memcpy.3       |  5 ++-
 man/man3/memfrob.3      |  2 +-
 man/man3/memmem.3       |  2 +-
 man/man3/memmove.3      |  5 ++-
 man/man3/mempcpy.3      |  2 +-
 man/man3/memrchr.3      |  2 +-
 man/man3/memset.3       |  5 ++-
 man/man3/stpncpy.3      |  8 +++-
 man/man3/strcasecmp.3   |  6 +++
 man/man3/strcmp.3       |  6 +++
 man/man3/strdup.3       |  5 +++
 man/man3/strdupa.3      |  4 ++
 man/man3/string.3       | 95 +++--------------------------------------
 man/man3/strncat.3      |  5 ++-
 man/man3/strnlen.3      |  5 ++-
 man/man3head/memory.h.3 | 57 +++++++++++++++++++++++++
 19 files changed, 126 insertions(+), 103 deletions(-)
 create mode 100644 man/man3head/memory.h.3

Range-diff:
-:  ------------ > 1:  784288e70418 man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>
-:  ------------ > 2:  668ab8c64821 man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head)

base-commit: 8152eb52d9a92f02c14e843545acec7ee1946479
-- 
2.53.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 13166 bytes --]

The standard mixes functions for handling strings, functions for
handling bytes, and other hybrids, all in a single header file:
<string.h>.

This has historically caused confusion, for example leading to believe
that strncpy(3) is appropriate to handle strings.

It turns out that mem*() functions haven't been always in <string.h>.
These functions were first introduced in 1983 in System V, and were
added in a separate <memory.h> file.  Very soon, they were added to
4.3BSD in 1986 for compatibility to System V, also in <memory.h>.

Most modern-day POSIX-compatible libc implementations still provide this
header file for backwards compatibility reasons:

	$ find ~/src/bsd/freebsd/main/ | grep /include/memory.h
	/home/alx/src/bsd/freebsd/main/include/memory.h
	$ find ~/src/bsd/netbsd/trunk/ | grep /include/memory.h
	/home/alx/src/bsd/netbsd/trunk/include/memory.h
	$ find ~/src/bsd/openbsd/master/ | grep /include/memory.h
	/home/alx/src/bsd/openbsd/master/include/memory.h
	$ find ~/src/gnu/glibc/master/ | grep /include/memory.h
	/home/alx/src/gnu/glibc/master/include/memory.h
	$ find ~/src/musl/libc/master/ | grep /include/memory.h
	/home/alx/src/musl/libc/master/include/memory.h

It seems that it was C89 that moved the mem*() functions to <string.h>,
even though the Rationale document for C89 doesn't mention it at all.

This was a huge mistake --we can see the consequences in the many
misuses of these functions, and programmers that believe they are
appropriate for uses for which they are unappropriate-- that we can undo
now.

Let's document these as provided by <memory.h>, which is still true;
all POSIX-ish libc implementations I've consulted provide the <memory.h>
header with mem*() functions, except two: Illumos gate, and gnulib.
Let's ignore them, or rather, hope they will follow suit eventually.

This will signal to programmers that this is the header file they should
be using.  The C Committee is discussing the possibility of
standardizing the good old <memory.h> header file, so let's give it a
little bump.

Let's also move the strn*() functions there, since modern libc
implementations also provide them there.  And they certainly don't
belong in <string.h>, so <memory.h> is more adequate.

After this change, <string.h> contains only functions that exclusively
handle (and require) strings.

Cc: Keith Bostic <keith@bostic.com>
Cc: Joseph Myers <josmyers@redhat.com>
Cc: Mark Harris <mark.hsj@gmail.com>
Cc: Nevin Liber <nevin@cplusplusguy.com>
Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>
Cc: Christopher Bazley <chris.bazley.wg14@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Iker Pedrosa <ipedrosa@redhat.com>
Cc: "Evgeny Grin (Karlson2k)" <k2k@drgrin.dev>
Cc: Kees Cook <keescook@chromium.org>
Cc: bug-gnulib@gnu.org
Cc: libc-alpha@sourceware.org
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 man/man3/memccpy.3    | 5 ++++-
 man/man3/memchr.3     | 5 ++++-
 man/man3/memcmp.3     | 5 ++++-
 man/man3/memcpy.3     | 5 ++++-
 man/man3/memfrob.3    | 2 +-
 man/man3/memmem.3     | 2 +-
 man/man3/memmove.3    | 5 ++++-
 man/man3/mempcpy.3    | 2 +-
 man/man3/memrchr.3    | 2 +-
 man/man3/memset.3     | 5 ++++-
 man/man3/stpncpy.3    | 8 +++++++-
 man/man3/strcasecmp.3 | 6 ++++++
 man/man3/strcmp.3     | 6 ++++++
 man/man3/strdup.3     | 5 +++++
 man/man3/strdupa.3    | 4 ++++
 man/man3/strncat.3    | 5 ++++-
 man/man3/strnlen.3    | 5 ++++-
 17 files changed, 64 insertions(+), 13 deletions(-)

diff --git a/man/man3/memccpy.3 b/man/man3/memccpy.3
index 706f8152f58c..a6bc4e8a3e0b 100644
--- a/man/man3/memccpy.3
+++ b/man/man3/memccpy.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "void *memccpy(" "size_t n;"
 .BI "              void " dest "[restrict " n "], const void " src "[restrict " n ],
@@ -67,6 +67,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, SVr4, 4.3BSD.
 .SH SEE ALSO
diff --git a/man/man3/memchr.3 b/man/man3/memchr.3
index 0a493ff4029d..f3ee95c00406 100644
--- a/man/man3/memchr.3
+++ b/man/man3/memchr.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "void *memchr(" "size_t n;"
 .BI "             const void " s [ n "], int " c ", size_t " n );
@@ -53,6 +53,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH SEE ALSO
diff --git a/man/man3/memcmp.3 b/man/man3/memcmp.3
index 9cecb282ba4f..467f24cb39a7 100644
--- a/man/man3/memcmp.3
+++ b/man/man3/memcmp.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "int memcmp(" "size_t n;"
 .BI "           const void " s1 [ n "], const void " s2 [ n "], size_t " n );
@@ -70,6 +70,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH CAVEATS
diff --git a/man/man3/memcpy.3 b/man/man3/memcpy.3
index f8f049bf5c4c..7083dc3f7577 100644
--- a/man/man3/memcpy.3
+++ b/man/man3/memcpy.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "void *memcpy(" "size_t n;"
 .BI "             void " dest "[restrict " n "], const void " src "[restrict " n ],
@@ -53,6 +53,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH CAVEATS
diff --git a/man/man3/memfrob.3 b/man/man3/memfrob.3
index ee41da0ced7b..ad736949002c 100644
--- a/man/man3/memfrob.3
+++ b/man/man3/memfrob.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "             /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *memfrob(" "size_t n;"
 .BI "              void " s [ n "], size_t " n );
diff --git a/man/man3/memmem.3 b/man/man3/memmem.3
index 13fd8b7cea7b..d0f99e6d577d 100644
--- a/man/man3/memmem.3
+++ b/man/man3/memmem.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "         /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *memmem(" "size_t hsize, size_t nsize;"
 .BI "             const void " haystack [ hsize "], size_t " hsize ,
diff --git a/man/man3/memmove.3 b/man/man3/memmove.3
index 99f152412142..65f6a67b9b35 100644
--- a/man/man3/memmove.3
+++ b/man/man3/memmove.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "void *memmove(" "size_t n;"
 .BI "              void " dest [ n "], const void " src [ n "], size_t " n );
@@ -56,6 +56,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH SEE ALSO
diff --git a/man/man3/mempcpy.3 b/man/man3/mempcpy.3
index 012e6326dd00..4598be5d7bc2 100644
--- a/man/man3/mempcpy.3
+++ b/man/man3/mempcpy.3
@@ -14,7 +14,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "         /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *mempcpy(" "size_t n;"
 .BI "              void " dest "[restrict " n "], const void " src "[restrict " n ],
diff --git a/man/man3/memrchr.3 b/man/man3/memrchr.3
index 6e49defc5e4a..fe2841147f05 100644
--- a/man/man3/memrchr.3
+++ b/man/man3/memrchr.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR #define\~_GNU_SOURCE "  // See feature_test_macros(7)"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR void\~*memrchr( size_t\~n;
 .BI "              const void " s [ n "], int " c ", size_t " n );
diff --git a/man/man3/memset.3 b/man/man3/memset.3
index 91b3b476abf9..b69398a7762a 100644
--- a/man/man3/memset.3
+++ b/man/man3/memset.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "void *memset(" "size_t n;"
 .BI "             void " s [ n "], int " c ", size_t " n );
@@ -48,6 +48,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH SEE ALSO
diff --git a/man/man3/stpncpy.3 b/man/man3/stpncpy.3
index 5b1ec5595169..4d959fde9f83 100644
--- a/man/man3/stpncpy.3
+++ b/man/man3/stpncpy.3
@@ -14,7 +14,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "char *strncpy(" "size_t dsize;"
 .BI "              char " dst "[restrict " dsize "], const char *restrict " src ,
@@ -97,9 +97,15 @@ .SH STANDARDS
 .TP
 .BR strncpy ()
 C11, POSIX.1-2008.
+.IP
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .TP
 .BR stpncpy ()
 POSIX.1-2008.
+.IP
+POSIX declares this function in
+.IR <string.h> .
 .SH HISTORY
 .TP
 .BR strncpy ()
diff --git a/man/man3/strcasecmp.3 b/man/man3/strcasecmp.3
index 65941ddf6524..a4100a0d0f02 100644
--- a/man/man3/strcasecmp.3
+++ b/man/man3/strcasecmp.3
@@ -15,6 +15,9 @@ .SH SYNOPSIS
 .B #include <strings.h>
 .P
 .BI "int strcasecmp(const char *" s1 ", const char *" s2 );
+.P
+.BR #include\~<memory.h> "  // See STANDARDS"
+.P
 .BI "int strncasecmp(const char " s1 "[], const char " s2 "[], size_t " n );
 .fi
 .SH DESCRIPTION
@@ -70,6 +73,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 POSIX.1-2008.
+.P
+POSIX declares both functions in
+.IR <string.h> .
 .SH HISTORY
 4.4BSD, POSIX.1-2001.
 .P
diff --git a/man/man3/strcmp.3 b/man/man3/strcmp.3
index 0a573e52d936..2909a0b7ea64 100644
--- a/man/man3/strcmp.3
+++ b/man/man3/strcmp.3
@@ -16,6 +16,9 @@ .SH SYNOPSIS
 .B #include <string.h>
 .P
 .BI "int strcmp(const char *" s1 ", const char *" s2 );
+.P
+.BR #include\~<memory.h> "  // See STANDARDS"
+.P
 .BR "int strncmp(const char " s1 "[], const char " s2 "[], size_t " n );
 .fi
 .SH DESCRIPTION
@@ -107,6 +110,9 @@ .SH VERSIONS
 (If the two characters are equal, this difference is 0.)
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare both functions in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH EXAMPLES
diff --git a/man/man3/strdup.3 b/man/man3/strdup.3
index f3ab0611a323..c12cd3071dd9 100644
--- a/man/man3/strdup.3
+++ b/man/man3/strdup.3
@@ -16,6 +16,8 @@ .SH SYNOPSIS
 .P
 .BI "char *strdup(const char *" s );
 .P
+.BR #include\~<memory.h> "  // See STANDARDS"
+.P
 .BR "char *strndup(" "size_t n;"
 .BI "              const char " s [ n "], size_t " n );
 .fi
@@ -93,6 +95,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 POSIX.1-2008.
+.P
+POSIX declares both functions in
+.IR <string.h> .
 .SH HISTORY
 .TP
 .BR strdup ()
diff --git a/man/man3/strdupa.3 b/man/man3/strdupa.3
index 63b12c83e9ec..412eec9f3491 100644
--- a/man/man3/strdupa.3
+++ b/man/man3/strdupa.3
@@ -16,6 +16,10 @@ .SH SYNOPSIS
 .B #include <string.h>
 .P
 .BI "char *strdupa(const char *" s );
+.P
+.BR "#define _GNU_SOURCE" "  /* See feature_test_macros(7) */"
+.B #include <memory.h>
+.P
 .BR "char *strndupa(" "size_t n;"
 .BI "              const char " s [ n "], size_t " n );
 .fi
diff --git a/man/man3/strncat.3 b/man/man3/strncat.3
index dd39d54939d9..dc74e0fefbc3 100644
--- a/man/man3/strncat.3
+++ b/man/man3/strncat.3
@@ -11,7 +11,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "char *strncat(" "size_t ssize;"
 .BI "              char *restrict " dst ", const char " src "[restrict " ssize ],
@@ -57,6 +57,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 C11, POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2001, C89, SVr4, 4.3BSD.
 .SH CAVEATS
diff --git a/man/man3/strnlen.3 b/man/man3/strnlen.3
index 553a39a9ec7a..657fc8c7ae9c 100644
--- a/man/man3/strnlen.3
+++ b/man/man3/strnlen.3
@@ -12,7 +12,7 @@ .SH LIBRARY
 .RI ( libc ,\~ \-lc )
 .SH SYNOPSIS
 .nf
-.B #include <string.h>
+.BR #include\~<memory.h> "  // See STANDARDS"
 .P
 .BR "size_t strnlen(const char " s "[], size_t " maxlen );
 .fi
@@ -83,6 +83,9 @@ .SH ATTRIBUTES
 .TE
 .SH STANDARDS
 POSIX.1-2008.
+.P
+ISO C and POSIX declare this function in
+.IR <string.h> .
 .SH HISTORY
 POSIX.1-2008.
 .SH SEE ALSO
-- 
2.53.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 2/2] man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]

See previous commit.

Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 man/man3/string.3       | 95 +++--------------------------------------
 man/man3head/memory.h.3 | 57 +++++++++++++++++++++++++
 2 files changed, 62 insertions(+), 90 deletions(-)
 create mode 100644 man/man3head/memory.h.3

diff --git a/man/man3/string.3 b/man/man3/string.3
index da87799a5e69..02c9897d8771 100644
--- a/man/man3/string.3
+++ b/man/man3/string.3
@@ -5,7 +5,7 @@
 .\"
 .TH string 3 (date) "Linux man-pages (unreleased)"
 .SH NAME
-string \- byte operations
+string \- string operations
 .SH LIBRARY
 Standard C library
 .RI ( libc ,\~ \-lc )
@@ -15,84 +15,25 @@ .SH SYNOPSIS
 .B #include <strings.h>
 .fi
 .SH DESCRIPTION
-.SS Write
-.TP
-Write bytes
-.RS
-.TP
-.BR bzero (3)
-.TQ
-.BR memset (3)
-.RE
 .SS Copy
 .TP
-Copy bytes
-.RS
-.TP
-.BR memmove (3)
-.TQ
-.BR memcpy (3)
-.TQ
-.BR mempcpy (3)
-.TQ
-.BR memccpy (3)
-.RE
-.TP
-Copy strings
-.RS
-.TP
 .BR strcpy (3)
 .TQ
 .BR stpcpy (3)
-.RE
-.TP
-Copy nonstrings
-.RS
-.TP
-.BR strncpy (3)
-.RE
 .SS Catenate
 .TP
-Catenate strings
-.RS
-.TP
 .BR strcat (3)
-.RE
-.TP
-Catenate nonstrings
-.RS
-.TP
-.BR strncat (3)
-.RE
 .SS Duplicate
 .TP
-Duplicate strings
-.RS
-.TP
 .BR strdup (3)
 .TQ
 .BR strdupa (3)
-.RE
-.TP
-Duplicate nonstrings
-.RS
-.TP
-.BR strndup (3)
-.TQ
-.BR strndupa (3)
-.RE
 .SS Compare
 .TP
-Compare bytes
-.RS
-.TP
 .BR memeq (3)
-.TQ
-.BR memcmp (3)
-.RE
-.TP
-Compare strings
-.RS
+.IP
+This function should be in
+.IR <memory.h> .
 .TP
 .BR streq (3)
 .TQ
@@ -103,30 +44,8 @@ .SS Compare
 .BR strcoll (3)
 .TQ
 .BR strverscmp (3)
-.RE
-.TP
-Compare nonstrings
-.RS
-.TP
-.BR strncmp (3)
-.TQ
-.BR strncasecmp (3)
-.RE
 .SS Search
 .TP
-Search bytes
-.RS
-.TP
-.BR memchr (3)
-.TQ
-.BR memrchr (3)
-.TQ
-.BR memmem (3)
-.RE
-.TP
-Search strings
-.RS
-.TP
 .BR strlen (3)
 .TQ
 .BR strnul (3)
@@ -146,18 +65,14 @@ .SS Search
 .BR strspn (3)
 .TQ
 .BR strcspn (3)
-.RE
 .SS Separate
 .TP
-Separate strings
-.RS
-.TP
 .BR strsep (3)
 .TQ
 .BR strtok (3)
-.RE
 .SS Others
 .TP
 .BR strxfrm (3)
 .SH SEE ALSO
+.BR memory.h (3head),
 .BR string_copying (7)
diff --git a/man/man3head/memory.h.3 b/man/man3head/memory.h.3
new file mode 100644
index 000000000000..786da968f9fd
--- /dev/null
+++ b/man/man3head/memory.h.3
@@ -0,0 +1,57 @@
+.\" Copyright 1993, David Metcalfe <david@prism.demon.co.uk>
+.\" Copyright, the authors of the Linux man-pages project
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.TH memory.h 3head (date) "Linux man-pages (unreleased)"
+.SH NAME
+memory.h \- memory operations
+.SH LIBRARY
+Standard C library
+.RI ( libc ,\~ \-lc )
+.SH SYNOPSIS
+.nf
+.B #include <memory.h>
+.fi
+.SH DESCRIPTION
+.SS Write
+.TP
+.BR bzero (3)
+.TQ
+.BR memset (3)
+.SS Copy
+.TP
+.BR memmove (3)
+.TQ
+.BR memcpy (3)
+.TQ
+.BR mempcpy (3)
+.TQ
+.BR memccpy (3)
+.TQ
+.BR strncpy (3)
+.SS Catenate
+.TP
+.BR strncat (3)
+.SS Duplicate
+.TP
+.BR strndup (3)
+.TQ
+.BR strndupa (3)
+.SS Compare
+.TP
+.BR memcmp (3)
+.TQ
+.BR strncmp (3)
+.TQ
+.BR strncasecmp (3)
+.SS Search
+.TP
+.BR memchr (3)
+.TQ
+.BR memrchr (3)
+.TQ
+.BR memmem (3)
+.SH SEE ALSO
+.BR string (3),
+.BR string_copying (7)
-- 
2.53.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al.

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 13850 bytes --]

> Date: 2026-07-31 23:18:54+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi!
> 
> Here's a patch set for documenting mem*(3) and strn*(3) functions as
> provided in <memory.h>.  This should put a stop to the misunderstanding
> and misuse of these functions as handling strings; they handle bytes and
> nonstrings (and in some cases, strings can be used as nonstrings or as
> byte arrays, but very carefully).
> 
> This header is quite portable: {Free,Net,Open}BSD, glibc, and musl, at
> least and since forever.
> 
> The C Committee is discussing standardization of <memory.h>, so let's
> give it a bump.

Here's a draft of the proposal:

---
Name
	alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al.

Principles
	-  Avoid ambiguities
	-  Codify existing practice to address evident deficiencies

Category
	Revert regression; library

Author
	Alejandro Colomar <alx@kernel.org>

	Cc: Mark Harris <mark.hsj@gmail.com>
	Cc: Nevin Liber <nevin@cplusplusguy.com>
	Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>
	Cc: Joseph Myers <josmyers@redhat.com>
	Cc: Keith Bostic <keith@bostic.com>

History
	<https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0097.git/>

	r0 (2026-07-31):
	-  Initial draft.

	r1 (2026-07-31):
	-  Avoid cd(1).

Rationale
	The standard mixes functions for handling strings, functions for
	handling bytes, and other hybrids, all in a single header file:
	<string.h>.

	This has historically caused confusion, as for example leading
	to believe that strncpy(3) is appropriate to handle strings.

	Let's separate the standard clearly into three different header
	files that differentiate these APIs.

    System V
	It turns out that mem*() functions haven't been always in
	<string.h>.  These functions were first introduced in 1983 in
	System V, and were added in a separate <memory.h> file.  Very
	soon, they were added to 4.3BSD in 1986 for compatibility to
	System V, also in <memory.h>.

	Most modern-day POSIX-compatible libc implementations still
	provide this header file for backwards compatibility reasons:

		$ find ~/src/bsd/freebsd/main/ | grep /include/memory.h
		/home/alx/src/bsd/freebsd/main/include/memory.h
		$ find ~/src/bsd/netbsd/trunk/ | grep /include/memory.h
		/home/alx/src/bsd/netbsd/trunk/include/memory.h
		$ find ~/src/bsd/openbsd/master/ | grep /include/memory.h
		/home/alx/src/bsd/openbsd/master/include/memory.h
		$ find ~/src/gnu/glibc/master/ | grep /include/memory.h
		/home/alx/src/gnu/glibc/master/include/memory.h
		$ find ~/src/musl/libc/master/ | grep /include/memory.h
		/home/alx/src/musl/libc/master/include/memory.h

    C89
	It seems that it was C89 that moved the mem*() functions to
	<string.h>, even though the Rationale document for C89 doesn't
	mention it at all.

	This was a huge mistake --we can see the consequences in the
	many misuses of these functions, and programmers that believe
	they are appropriate for uses that they are unappropriate-- that
	we can undo now.

    Design decisions
	To avoid breaking the world, let's provide the declarations of
	mem*() in both <string.h> and the old-but-new <memory.h>.  This
	will allow existing programs to continue working without
	changes.  It will also allow new programs to use the more
	higienic header files.

	This is actually what is done by existing implementations, which
	provide the declarations in both header files.  So, this is
	standardization of prior art.

    <nonstring.h>
	The strn*() functions didn't have their own separate header, but
	to avoid miususe, let's have a third header file for them.
	The name comes from the GCC [[gnu::nonstring]] attribute, which
	is used to refer to things that are somewhat similar to a string
	but aren't really a string (they are not necessarily
	NUL-terminated).

	Strings are valid nonstrings, but not the other way around.
	This is why some strn*() functions still work well on strings,
	such as strncmp(3).  However, that shouldn't prevent moving them
	to this header file.

	Also, some strn*() functions work with strings in some
	parameters, while taking nonstrings in others.  For example,
	strncat(3) takes a nonstring, and produces a string; and
	strncpy(3) takes a string (or a nonstring), and produces a
	nonstring.  Let's put all of these in <nonstring.h>, so that
	<string.h> will remain as a header file for functions that
	*exclusively* handle strings.

    <wchar.h>
	Because <wchar.h> is already more packed than <string.h>,
	containing also stuff that would correspond to other headers
	(e.g., wcstol(3)), let's not split that one.  A refactor of
	<wchar.h> should entertain a much larger task, and create files
	such as <wstring.h>, <wstdlib.h>, <wmemory.h>, etc.

Proposed wording
	Based on N3886.

    7  Library
	@@ New subclause after 7.27 ("_Noreturn <stdnoreturn.h>")
	+7.<27+1>  Memory handling <memory.h>
	+7.<27+1>.1  Memory function conventions

	@@ Copy 7.28.1p1 as 7.<27+1>.1p1, then:
	 The header
	-<string.h>
	+<memory.h>
	 declares one type,
	 several functions,
	-several type-generic functions,
	+one type-generic function,
	 and defines two macros
	 useful for manipulating
	-arrays of character type and other
	 objects
	 treated as arrays of character type.
	-328)
	+AAA)
	 The type is <b>size_t</b>
	 and one of the macros is <b>NULL</b>
	 (both described in 7.22).
	 Various methods are used for
	 determining the lengths of the arrays,
	 but in all cases a
	-<b>char *</b> or
	 <b>void *</b> argument
	 points to
	 the initial (lowest addressed) character
	 of the array.
	 If an array is accessed beyond the end of an object,
	 the behavior is undefined.
	+
	+AAA)
	+	See "future library directions" (7.35.<17+1>)

	@@ p2
	+2
	+	The macro
	+		__STDC_VERSION_MEMORY_H__
	+	is an integer constant expression
	+	with a value equivalent to <tt>202ymmL</tt>.

	@@
	## Copy 7.28.1p3 as 7.<27+1>.1p3, verbatim.
	## Copy 7.28.1p4 as 7.<27+1>.1p4, verbatim.

	+7.<27+1>.2  Copying functions
	## Move 7.28.2.1 as 7.<27+1>.2.1 ("The memcpy function").
	## Move 7.28.2.2 as 7.<27+1>.2.2 ("The memccpy function").
	## Move 7.28.2.3 as 7.<27+1>.2.3 ("The memmove function").

	+7.<27+1>.3  Comparison functions
	+7.<27+1>.3.1  General
	@@ Copy 7.28.4.1p1 as 7.<27+1>.3.1p1, then:
	 The sign of a nonzero value
	 returned by the comparison functions
	 <b>memcmp</b>
	-, strcmp, and strncmp
	 is determined by the sign of
	 the difference between
	 the values of the first pair of characters
	 (both interpreted as unsigned char)
	 that differ in the objects being compared.

	@@
	## Move 7.28.4.2 as 7.<27+1>.3.2 ("The memcmp function").

	+7.<27+1>.4  Search functions
	+7.<27+1>.4.1  Introduction
	@@ Copy 7.28.5.1p1 as 7.<27+1>.4.1p1, then:
	 The stateless search functions
	 in this subclause
	 (<b>memchr</b>
	-, strchr, strpbrk, strrchr, strstr
	 )
	 are <i>generic functions</i>.
	 These functions are
	 generic
	 in the qualification of the array to be searched
	 and will return a result pointer to an element
	 with the same qualification as the passed array.
	 If the array to be searched is <b>const</b>-qualified,
	 the result pointer will be to a <b>const</b>-qualified element.
	 If the array to be searched is not <b>const</b>-qualified,
	-332)
	+BBB)
	 the result pointer will be to an unqualified element.

	## Copy footnote 332) as BBB), verbatim.

	@@ Copy 7.28.5.1p2 as 7.<27+1>.4.1p2, then:
	 The external declarations
	 of these generic functions
	 have a concrete function type
	 that returns a pointer to an unqualified element
	-(
	 of type
	-<b>char</b> when specified as <bi>QChar</bi>, and
	 <b>void</b>
	-when specified as <bi>QVoid</bi>
	-)
	 ,
	 and accepts a pointer to
	 a <b>const</b>-qualified array of the same type to search.
	 This signature supports all correct uses.
	 If the macro definition of
	 any of these generic functions
	 is suppressed to access
	 an actual function,
	 the external declaration
	 with the corresponding concrete type is visible.
	-333)
	+CCC)

	@@
	## Copy footnote 333) as CCC), verbatim.
	## Copy 7.28.5.1p3 as 7.<27+1>.4.1p3, verbatim.

	@@
	## Move 7.28.5.2 as 7.<27+1>.4.2 ("The memchr function").

	+7.<27+1>.5  Miscellaneous functions
	## Move 7.28.6.1 as 7.<27+1>.5.1 ("The memset function").
	## Move 7.28.6.2 as 7.<27+1>.5.2 ("The memset_explicit function").

    7.28  String handling <string.h>
	@@ New subsection after title
	+7.28.<0+1>  General
	+1
	+	The header <string.h>
	+	includes the headers <memory.h> and <nonstring.h>.

	@@
	## Move 7.28.1p2 as 7.28.<0+1>p2, verbatim.

    7.28.1  String function conventions
	## Delete p2 --moved elsewhere--.

    7.28.2  Copying functions
	## Delete 7.28.2.1 ("The memcpy function") --moved elsewhere--.
	## Delete 7.28.2.2 ("The memccpy function") --moved elsewhere--.
	## Delete 7.28.2.3 ("The memmove function") --moved elsewhere--.
	## Delete 7.28.2.5 ("The strncpy function") --moved elsewhere--.
	## Delete 7.28.2.7 ("The strndup function") --moved elsewhere--.

    7.28.3  Concatenation functions
	@@ Title
	-Concatenation
	+Catenation

	@@
	## Delete 7.28.3.2 ("The strncat function") --moved elsewhere--.

    7.28.4.1  Comparison functions :: General
	@@ p1
	 The sign of a nonzero value
	 returned by the comparison functions
	+(
	-memcmp,
	 strcmp
	-, and strncmp
	+)
	 is determined by the sign of the difference
	 between the values of the first pair of characters
	 (both interpreted as unsigned char)
	 that differ in the objects being compared.

    7.28.4  Comparison functions
	## Delete 7.28.4.2 ("The memcmp function") --moved elsewhere--.
	## Delete 7.28.4.5 ("The strncmp function") --moved elsewhere--.

    7.28.5.1  Search functions :: Introduction
	@@ p1
	 The stateless search functions
	 in this subclause
	 (
	-memchr,
	 <b>strchr</b>, <b>strpbrk</b>, <b>strrchr</b>, <b>strstr</b>
	 )
	 are <i>generic functions</i>.
	 These functions are
	 generic
	 in the qualification of the array to be searched
	 and will return a result pointer to an element
	 with the same qualification as the passed array.
	 If the array to be searched is <b>const</b>-qualified,
	 the result pointer will be to a <b>const</b>-qualified element.
	 If the array to be searched is not <b>const</b>-qualified,
	 332)
	 the result pointer will be to an unqualified element.

	@@ p2
	 The external declarations
	 of these generic functions
	 have a concrete function type
	 that returns a pointer to an unqualified element
	-(
	 of type <b>char</b>
	-when specified as <bi>QChar</bi>,
	-and <b>void</b>
	-when specified as <bi>QVoid</bi>
	-)
	 ,
	 and accepts a pointer to
	 a <b>const</b>-qualified array of the same type to search.
	 This signature supports all correct uses.
	 If the macro definition of
	 any of these generic functions
	 is suppressed to access
	 an actual function,
	 the external declaration
	 with the corresponding concrete type is visible.
	 333)

    7.28.5  Search functions
	## Delete 7.28.5.2 ("The memchr function") --moved elsewhere--.

    7.28.6  Miscellaneous functions
	## Delete 7.28.6.1 ("The memset function") --moved elsewhere--.
	## Delete 7.28.6.2 ("The memset_explicit function") --moved elsewhere--.
	## Delete 7.28.6.5 ("The strnlen function") --moved elsewhere--.

    7  Library
	@@ New subclause after 7.28 ("String handling <string.h>").
	+7.<28+1>  Nonstring handling <nonstring.h>
	+7.<28+1>.1  Nonstring function conventions

	@@ Copy 7.28.1p1 as 7.<28+1>.1p1, then:
	 The header
	-<string.h>
	+<nonstring.h>
	 declares one type,
	 several functions,
	-several type-generic functions,
	 and defines two macros
	 useful for manipulating
	 arrays of character type and other
	 objects
	 treated as arrays of character type.
	-328)
	+DDD)
	 The type is <b>size_t</b>
	 and one of the macros is <b>NULL</b>
	 (both described in 7.22).
	 Various methods are used for
	 determining the lengths of the arrays,
	 but in all cases a
	 <b>char *</b>
	-or <b>void *</b>
	 argument
	 points to
	 the initial (lowest addressed)
	 character
	 of the array.
	 If an array is accessed beyond the end of an object,
	 the behavior is undefined.
	+
	+DDD)
	+	See "future library directions" (7.35.<18+1>)

	@@ p2
	+2
	+	The macro
	+		__STDC_VERSION_NONSTRING_H__
	+	is an integer constant expression
	+	with a value equivalent to <tt>202ymmL</tt>.

	@@
	## Copy 7.28.1p3 as 7.<28+1>.1p3, verbatim.
	## Copy 7.28.1p4 as 7.<28+1>.1p4, verbatim.

	+7.<28+1>.2  Copying functions
	## Move 7.28.2.5 as 7.<28+1>.2.1 ("The strncpy function").
	## Move 7.28.2.7 as 7.<28+1>.2.2 ("The strndup function").

	+7.<28+1>.3  Catenation functions
	## Move 7.28.3.2 as 7.<28+1>.3.1 ("The strncat function").

	+7.<28+1>.4  Comparison functions
	+7.<28+1>.4.1  General
	@@ Copy 7.28.4.1p1 as 7.<28+1>.4.1p1, then:
	 The sign of a nonzero value
	 returned by the comparison functions
	-memcmp, strcmp, and
	+(
	 <b>strncmp</b>
	+)
	 is determined by the sign of
	 the difference between
	 the values of the first pair of characters
	 (both interpreted as unsigned char)
	 that differ in the objects being compared.

	@@
	## Move 7.28.4.5 as 7.<28+1>.4.2 ("The strncmp function").

	+7.<28+1>.5  Miscellaneous functions
	## Move 7.28.6.5 as 7.<28+1>.5.1 ("The strnlen function").

	## I've kept plurals in sections that only have one function.
	## This is because we may add functions in the future, so it's
	## better to keep the wording generic to avoid having to update
	## it needlessly.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Joseph Myers]

I think it's irresponsible to use the man-pages project to promote 
personal idiosyncratic ideas like this in preference to what's been the 
standard location of functions since 1989.

I'd rather we add a mandatory deprecation warning to memory.h in glibc.

-- 
Joseph S. Myers
josmyers@redhat.com

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Hi Joseph,

> Date: 2026-07-31 21:23:35+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> I think it's irresponsible to use the man-pages project to promote 
> personal idiosyncratic ideas like this in preference to what's been the 
> standard location of functions since 1989.
> 
> I'd rather we add a mandatory deprecation warning to memory.h in glibc.

I hope you don't; it'd be a gratuitous breaking change.


Have a lovely night!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Hi Joseph,

At 2026-07-31T21:23:35+0000, Joseph Myers wrote:
> I think it's irresponsible to use the man-pages project to promote
> personal idiosyncratic ideas like this in preference to what's been
> the standard location of functions since 1989.

I'm sure I don't need to bring to your attention what a mine field
string/`char` sequence/memory buffer handling has been in C since the
language's inception.

More to the point: what's a better forum for pursuing this attempt at
reform that will both (a) reach a significant population of stakeholders
who can variously red-team it and/or endorse it; and (b) has sufficient
visibility that it can't easily be ignored by people who oppose reform
in this area for whatever reason?

I hope you do not wish to imply that a closed session of some committee,
or unofficial backroom politicking would be preferable, nor that WG14
should close its doors to members of its user community who have not
been vetted for a disinclination to boat-rocking.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

Alejandro Colomar <alx@kernel.org> writes:

> Hi Joseph,
>
>> Date: 2026-07-31 21:23:35+0000
>> From: Joseph Myers <josmyers@redhat.com>
>>
>> I think it's irresponsible to use the man-pages project to promote 
>> personal idiosyncratic ideas like this in preference to what's been the 
>> standard location of functions since 1989.
>> 
>> I'd rather we add a mandatory deprecation warning to memory.h in glibc.
>
> I hope you don't; it'd be a gratuitous breaking change.
>

Yet this change has the same effect, just people will see it themselves
rather than the compiler telling them, and go around sending patches to
change it.

The man pages should reflect what the standard currently says, not what
you'd like it to say. We had the same problem with e.g. stripping "C89"
everywhere. People want it to reflect what the standard says.

>
> Have a lovely night!
> Alex

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: on the irresponsibility of pursuing C language reform

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

> Hi Joseph,
>
> At 2026-07-31T21:23:35+0000, Joseph Myers wrote:
>> I think it's irresponsible to use the man-pages project to promote
>> personal idiosyncratic ideas like this in preference to what's been
>> the standard location of functions since 1989.
>
> I'm sure I don't need to bring to your attention what a mine field
> string/`char` sequence/memory buffer handling has been in C since the
> language's inception.
>
> More to the point: what's a better forum for pursuing this attempt at
> reform that will both (a) reach a significant population of stakeholders
> who can variously red-team it and/or endorse it; and (b) has sufficient
> visibility that it can't easily be ignored by people who oppose reform
> in this area for whatever reason?
>

I think the man page already tries to discourage use in its CAVEATS
section.

> I hope you do not wish to imply that a closed session of some committee,
> or unofficial backroom politicking would be preferable, nor that WG14
> should close its doors to members of its user community who have not
> been vetted for a disinclination to boat-rocking.

I am confused as to where that implication could have possibly come
from. Joseph is opposing the change in the form of a patch that is
likely to be applied (*) to man-pages.git which has the effect of
advocacy.

I don't think it has anything to do with WG14 membership or anything of
the like? What am I missing?

(*) Alex has a history of making opinonated changes like this to
man-pages, such as removing references to older standards, and using a
somewhat novel (to many) syntax for prototypes.

>
> Regards,
> Branden

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Hi Joseph,

> Date: 2026-07-31 21:23:35+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> I think it's irresponsible to use the man-pages project to promote 
> personal idiosyncratic ideas like this in preference to what's been the 
> standard location of functions since 1989.

That's 37 years.  During these 37 years we have gathered a lot of
experience and data about this.  And the conclusion is that it was
a huge mistake.  Programmers have struggled to understand this, and
continue struggling.  This is not about new programmers.  This includes
programmers that have been around for decades, including maintainers of
core projects in which we all rely.

The move from <memory.h> to <string.h> seems to be entirely unjustified,
and was unilateral by the C Committee for C89 (from what I can see).

It's easy to see that all these problems about string handling would
probably be significantly less if these functions had never been
moved to <string.h>.

I agree that changing stuff that has been unchanged for decades should
usually be avoided, be done very carefully, and with strong
justification.  But in this case, it's justified, and doesn't break any
existing or new code, because <memory.h> has been provided since
forever.


Cheers,
Alex

> 
> I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Joseph Myers]

On Fri, 31 Jul 2026, G. Branden Robinson wrote:

> More to the point: what's a better forum for pursuing this attempt at
> reform that will both (a) reach a significant population of stakeholders
> who can variously red-team it and/or endorse it; and (b) has sufficient
> visibility that it can't easily be ignored by people who oppose reform
> in this area for whatever reason?

man-pages should document the world of C APIs as it is, in a way that has 
broad community agreement; it should follow, not lead, on any changes.

When an API has been in <string.h> since 1989, that means documenting 
<string.h> as the main location for that API - not some other location one 
person thinks is better and that most of the community has never heard of.

Of course, where there is broad agreement on a deficiency in a particular 
API, it's entirely appropriate for man-pages to document it (for example, 
to warn against certain naive uses of strncpy or strncat and make clear 
the very specific use case those functions are intended for - but not to 
promote one person's idea of alternative names for those functions).

-- 
Joseph S. Myers
josmyers@redhat.com

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

[Joseph Myers]

On Sat, 1 Aug 2026, Alejandro Colomar wrote:

> That's 37 years.  During these 37 years we have gathered a lot of
> experience and data about this.  And the conclusion is that it was
> a huge mistake.  Programmers have struggled to understand this, and

No, there's no such conclusion.  Two functions, strncpy and strncat, are 
with hindsight confusing (but it's the names and semantics rather than the 
header that are confusing).  I don't think there's any kind of community 
consensus at all that there's any problem with mem* being in <string.h>, 
or any functions other than those two.

The committee writing C89 had to come up with a compromise between 
functions such as memcpy and strchr and functions such as bcopy and index.  
They chose to adopt memcpy and strchr, and chose to put them in 
<string.h>, and there's no evidence since then to suggest a problem with 
either choice.

-- 
Joseph S. Myers
josmyers@redhat.com

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

Hi Sam,

> Date: 2026-07-31 22:54:27+0100
> From: Sam James <sam@gentoo.org>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Hi Joseph,
> >
> >> Date: 2026-07-31 21:23:35+0000
> >> From: Joseph Myers <josmyers@redhat.com>
> >>
> >> I think it's irresponsible to use the man-pages project to promote 
> >> personal idiosyncratic ideas like this in preference to what's been the 
> >> standard location of functions since 1989.
> >> 
> >> I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> >
> > I hope you don't; it'd be a gratuitous breaking change.
> >
> 
> Yet this change has the same effect, just people will see it themselves
> rather than the compiler telling them, and go around sending patches to
> change it.

IME, people don't go changing includes unless they need something it's
not available in the already-included header files.

Analysis of includes is quite complex, and there are tools for that
--iwyu(1)--.  As long as those tools don't start complaining --and they
won't-- [1], I find it quite unlikely that people will start changing
includes in existing code.

This is rather something that will affect new code (new source files).

[1]	iwyu(1) works in a way that it allows a number of headers to
	provide a symbol.  If no header provides the symbol, then it
	will recommend the best header for it; but if a header that
	provides the symbol is already there, it won't complain.

> The man pages should reflect what the standard currently says, not what
> you'd like it to say.

Not exactly; the standard is a good guideline, but sometimes it's off.
We have vendor extensions, which are well documented, and when the
standard is bogus, the extensions take over the page.

FWIW, the information from the standard is still there.

	$ MANWIDTH=64 mansectf STANDARDS man3/memcpy.3 | cat
	memcpy(3)           Library Functions Manual          memcpy(3)

	STANDARDS
	     C11, POSIX.1‐2008.

	     ISO C and POSIX declare this function in <string.h>.

	Linux man‐pages (unreleased) (date)                   memcpy(3)

I've just removed it from the front of the page (SYNOPSIS), but it's
still there, because of course, we must document the standard alongside
the extension.

> We had the same problem with e.g. stripping "C89"
> everywhere.

Sorry for that one; it was a useful change, though.  Now we have better
manual pages than we had back then, regarding standards.  I hope you
realize about that.  It triggered discussion, and a careful review of
the text, which resulted in a good change after all.

> People want it to reflect what the standard says.

And it still does.


Have a lovely night!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hi Joseph,

> Date: 2026-07-31 22:10:13+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> On Fri, 31 Jul 2026, G. Branden Robinson wrote:
> 
> > More to the point: what's a better forum for pursuing this attempt at
> > reform that will both (a) reach a significant population of stakeholders
> > who can variously red-team it and/or endorse it; and (b) has sufficient
> > visibility that it can't easily be ignored by people who oppose reform
> > in this area for whatever reason?
> 
> man-pages should document the world of C APIs as it is, in a way that has 
> broad community agreement; it should follow, not lead, on any changes.
> 
> When an API has been in <string.h> since 1989, that means documenting 
> <string.h> as the main location for that API - not some other location one 
> person thinks is better and that most of the community has never heard of.

FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
System V they go back further to 1983.


Have a lovely night!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]

Hi Sam,

At 2026-07-31T22:59:47+0100, Sam James wrote:
> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
> > At 2026-07-31T21:23:35+0000, Joseph Myers wrote:
> >> I think it's irresponsible to use the man-pages project to promote
> >> personal idiosyncratic ideas like this in preference to what's been
> >> the standard location of functions since 1989.
> >
> > I'm sure I don't need to bring to your attention what a mine field
> > string/`char` sequence/memory buffer handling has been in C since the
> > language's inception.
> >
> > More to the point: what's a better forum for pursuing this attempt at
> > reform that will both (a) reach a significant population of stakeholders
> > who can variously red-team it and/or endorse it; and (b) has sufficient
> > visibility that it can't easily be ignored by people who oppose reform
> > in this area for whatever reason?
> 
> I think the man page already tries to discourage use in its CAVEATS
> section.

Yes, but that's not a language reform, which is what Alex is pursuing
with "alx-0097r1".  In at least one earlier iteration he's expressed his
intention to submit an N document to WG14.

> > I hope you do not wish to imply that a closed session of some
> > committee, or unofficial backroom politicking would be preferable,
> > nor that WG14 should close its doors to members of its user
> > community who have not been vetted for a disinclination to
> > boat-rocking.
> 
> I am confused as to where that implication could have possibly come
> from.

From familiarity with Alex's stated objective and rationale, which we
can acquire from the recent list traffic Joseph characterized as
irresponsible.

AC> The C Committee is discussing standardization of <memory.h>, so
AC> let's give it a bump.

AC> I'll send you a copy of a paper I'm writing for the C Committee.

AC> It is at the bottom of this email.  I will publish it as an N
AC> document in August.

https://lore.kernel.org/linux-man/784288e704183a4297aeaa3d13af8edab18bc1ea.1785532392.git.alx@kernel.org/
https://lore.kernel.org/linux-man/amaTpQxd52iYjlor@devuan/

> Joseph is opposing the change in the form of a patch that is
> likely to be applied (*) to man-pages.git which has the effect of
> advocacy.

Yes, and he said so categorically.  More constructive advice might have
taken the form of recommending a sequencing for staged changes.  Here's
a crude sketch.

1.  Expand "CAVEATS" sections in relevant Linux man-pages documents.
2.  Pursue N-document work with WG14.
3.  When WG14 has disposed of that N-document (and any descendants
    thereof), update Linux man-pages documents as appropriate.

Joseph's almost certainly better placed than I to add a "step 1.5"
such that Alex might pursue some course that would better prepare the
ground for his step 2.  I haven't attempted revision of the C language
standard myself, so I can't offer specific advice regarding how best to
pursue such an objective.  I possess only notions of elemental
principles regarding how democratic, consultative bodies of technical
experts _should_ serve the public.

That _is_ what we're here for, right?

> I don't think it has anything to do with WG14 membership or anything
> of the like? What am I missing?

See above regarding Alex's publicly circulated drafts and expressed
plans.

> (*) Alex has a history of making opinonated changes like this to
>     man-pages, such as removing references to older standards, and
>     using a somewhat novel (to many) syntax for prototypes.

I concur with that assessment.  However, a person having a history of
making opinionated changes is not sound grounds for evaluation of a
technical proposal, especially if it's topically unrelated.

Preoccupying oneself with irrelevancies distracts from the conscientious
execution of standards committee participation.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Hi Alex,

At 2026-08-01T00:21:34+0200, Alejandro Colomar wrote:
> > Date: 2026-07-31 22:10:13+0000
> > From: Joseph Myers <josmyers@redhat.com>
> > man-pages should document the world of C APIs as it is, in a way
> > that has broad community agreement; it should follow, not lead, on
> > any changes.
> > 
> > When an API has been in <string.h> since 1989, that means
> > documenting <string.h> as the main location for that API - not some
> > other location one person thinks is better and that most of the
> > community has never heard of.
> 
> FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
> System V they go back further to 1983.

I meant to respond earlier with this research tidbit, but I've been busy
with preparing groff 1.25.0.rc2 and Mark Harris stepped in with much the
same info.  Thanks, Mark!

https://github.com/ryanwoodsmall/oldsysv/blob/master/sysv-pdp11_tape/usr/include/memory.h

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Hi Joseph,

> Date: 2026-07-31 22:16:14+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
> 
> > That's 37 years.  During these 37 years we have gathered a lot of
> > experience and data about this.  And the conclusion is that it was
> > a huge mistake.  Programmers have struggled to understand this, and
> 
> No, there's no such conclusion.  Two functions, strncpy and strncat, are 
> with hindsight confusing (but it's the names and semantics rather than the 
> header that are confusing).

Those are the most misused, indeed.

>  I don't think there's any kind of community 
> consensus at all that there's any problem with mem* being in <string.h>, 
> or any functions other than those two.

But it's a consistent solution that keeps all existing functions (thus,
not a breaking change), and puts them in a header file that is
appropriate (and which has been their header since 1986).

> The committee writing C89 had to come up with a compromise between 
> functions such as memcpy and strchr and functions such as bcopy and index.  
> They chose to adopt memcpy and strchr,

This was a good choice.  mem*() were more portable back then.

> and chose to put them in 
> <string.h>,

This wasn't a good choice.  They were already in <memory.h> in existing
systems.

> and there's no evidence since then to suggest a problem with 
> either choice.

We disagree.


Cheers,
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Joseph Myers]

On Sat, 1 Aug 2026, Alejandro Colomar wrote:

> > When an API has been in <string.h> since 1989, that means documenting 
> > <string.h> as the main location for that API - not some other location one 
> > person thinks is better and that most of the community has never heard of.
> 
> FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
> System V they go back further to 1983.

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.

Standards involve accepting agreed compromises that might not have been 
your first choice, rather than endlessly relitigating past disputes 
without new evidence or changed circumstances.  In this case, the choice 
of where to put the functions in C89 was an agreed compromise that 
implicitly obsoleted the previous location, and should have put an end to 
any arguments that <string.h> was a bad location for those functions in 
the absence of clear new evidence.  We have plenty of clear evidence for 
confusion about strn*; we don't about mem*.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]

Hi Joseph,

> Date: 2026-07-31 22:42:00+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
> 
> > > When an API has been in <string.h> since 1989, that means documenting 
> > > <string.h> as the main location for that API - not some other location one 
> > > person thinks is better and that most of the community has never heard of.
> > 
> > FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
> > System V they go back further to 1983.
> 
> 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.

FWIW, memccpy(3) was resurrected in C23 back from a cold death it had
been suffering since forever.  And that was less justified.

> Standards involve accepting agreed compromises that might not have been 
> your first choice, rather than endlessly relitigating past disputes 
> without new evidence or changed circumstances.  In this case, the choice 
> of where to put the functions in C89 was an agreed compromise that 
> implicitly obsoleted the previous location, and should have put an end to 
> any arguments that <string.h> was a bad location for those functions in 
> the absence of clear new evidence.

I agree that it wasn't necessarily obvious back then that the movement
to <string.h> was bad.  While I blame the C89 Committee for other stuff
they should have been aware of, this isn't one of them.

But now in 2026, we see that there have some been problems.

> We have plenty of clear evidence for 
> confusion about strn*; we don't about mem*.

Thanks!  Now we have a common ground.

Indeed, while there might be a minimal problem with mem*() --the fact
of not starting by str makes them less misused--, the important problem
is strn*().

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.

It wouldn't be reasonable to move strn*() to <memory.h>, and then leave
mem*() in <string.h>, of course.

Similarly, it wouldn't be reasonable to more strncpy/cat() to <memory.h>
and leave the rest of strn*() and all of mem*() in <string.h>.

This movement, while a bit massive, is consistent and self-explicative.
That is, the only reasonable way to move strncpy/cat() is to also move
strn*() and mem*().


Cheers,
Alex

> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]

Hi Joseph,

At 2026-07-31T22:42:00+0000, Joseph Myers wrote:
> Standards involve accepting agreed compromises that might not have
> been your first choice, rather than endlessly relitigating past
> disputes without new evidence or changed circumstances.  In this case,
> the choice of where to put the functions in C89 was an agreed
> compromise that implicitly obsoleted the previous location, and should
> have put an end to any arguments that <string.h> was a bad location
> for those functions in the absence of clear new evidence.  We have
> plenty of clear evidence for confusion about strn*; we don't about
> mem*.

What are some good ways to gather evidence that:

* ...C programmers since 1989 have gotten better at recognizing when
  they're dealing with "memory buffers" versus "strings"?
* ...that the header file's name has aided or frustrated that
  recognition process?
* ...that consequences of whatever confusion persists are more severe
  than the C Committee measured in 1989?

You can tell by my phrasing which way I _suspect_ the evidence points,
but I'll openly admit I don't have quantiative data.

But I think bringing such information to bear makes a stronger case than
a simple appeal to 37 years of precedent.

Occasionally, matters get relitigated because they had been wrongly
decided.  I appreciate the trend since 2000 or so of Stroustrup (with
respect to C++) and the Austin Group (with respect to POSIX) becoming
more open about where the bodies are buried, and how certain
standardization decisions have been reversed (through deprecation,
withdrawal, and similar) because a powerful vendor took its leave and
was no longer around to filibuster constructive development until its
demands were met.

I seem to recall Stroustrup calling out Sun Microsystems by name in the
4th edition of his main C++ book.  (Something to do with the exception
propagation mechanism, I think.)

I suggest to WG14 that a good way to reduce relitigation is to
candidly disclose in informative sections of the standard corresponding
to applicable topics, where the committee as constituted at the time of
issue has reached exhaustion with a matter.  (Though I wonder if ISO
would insist that such language be ripped out.)

I followed the C23 standarization process closely, and it looks as if
the National Bodies (NB) very nearly fought WG14 to exhaustion regarding
trigraphs.  I was greatly relieved that you guys won that one.

Back to the topic at hand, in data processing we tend to strongly
distinguish three forms of storage management:

1.  base and bounds (mem*)
2.  delimited (if with null bytes, str[^n]*)
3.  fixed-field (strn*, but not very consistently)

From one perspective, 1 and 3 are really the same, but from another
they're not, because, as some thousands of CVEs have shown, programmers
thinking of case 3 tend to assume that the field will be populated with
elements that are "well-behaved" in some way, whereas in case 1 they
tend even more strongly to be conscious that the storage could be
populated with arbitrary or even malicious garbage.

Do your impressions match mine in this area?

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Joseph Myers]

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.

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).  Any reasonable change there would involve a new 
header, say <strnpad.h> for strncpy and strncat, rather than resurrecting 
a very old one.

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

It's inconsistent with how people have understood C ever since it was 
standardized.  Changing the header memcpy is in is just as ridiculous at 
this point as the proposal there once was to obsolesce NULL.

> It wouldn't be reasonable to move strn*() to <memory.h>, and then leave
> mem*() in <string.h>, of course.
> 
> Similarly, it wouldn't be reasonable to more strncpy/cat() to <memory.h>
> and leave the rest of strn*() and all of mem*() in <string.h>.

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.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 5139 bytes --]

Hi Branden,

> Date: 2026-07-31 17:24:17-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Sam,
> 
> At 2026-07-31T22:59:47+0100, Sam James wrote:
> > "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
> > > At 2026-07-31T21:23:35+0000, Joseph Myers wrote:
> > >> I think it's irresponsible to use the man-pages project to promote
> > >> personal idiosyncratic ideas like this in preference to what's been
> > >> the standard location of functions since 1989.
> > >
> > > I'm sure I don't need to bring to your attention what a mine field
> > > string/`char` sequence/memory buffer handling has been in C since the
> > > language's inception.
> > >
> > > More to the point: what's a better forum for pursuing this attempt at
> > > reform that will both (a) reach a significant population of stakeholders
> > > who can variously red-team it and/or endorse it; and (b) has sufficient
> > > visibility that it can't easily be ignored by people who oppose reform
> > > in this area for whatever reason?
> > 
> > I think the man page already tries to discourage use in its CAVEATS
> > section.
> 
> Yes, but that's not a language reform, which is what Alex is pursuing
> with "alx-0097r1".  In at least one earlier iteration he's expressed his
> intention to submit an N document to WG14.

Indeed.

> > > I hope you do not wish to imply that a closed session of some
> > > committee, or unofficial backroom politicking would be preferable,
> > > nor that WG14 should close its doors to members of its user
> > > community who have not been vetted for a disinclination to
> > > boat-rocking.
> > 
> > I am confused as to where that implication could have possibly come
> > from.
> 
> From familiarity with Alex's stated objective and rationale, which we
> can acquire from the recent list traffic Joseph characterized as
> irresponsible.
> 
> AC> The C Committee is discussing standardization of <memory.h>, so
> AC> let's give it a bump.
> 
> AC> I'll send you a copy of a paper I'm writing for the C Committee.
> 
> AC> It is at the bottom of this email.  I will publish it as an N
> AC> document in August.
> 
> https://lore.kernel.org/linux-man/784288e704183a4297aeaa3d13af8edab18bc1ea.1785532392.git.alx@kernel.org/
> https://lore.kernel.org/linux-man/amaTpQxd52iYjlor@devuan/

Thanks for posting the links.  I've seen Doug was CCd on the second, so
I've bounced him the patch set and alx-0097r1, in case he's interested.

> 
> > Joseph is opposing the change in the form of a patch that is
> > likely to be applied (*) to man-pages.git which has the effect of
> > advocacy.
> 
> Yes, and he said so categorically.  More constructive advice might have
> taken the form of recommending a sequencing for staged changes.  Here's
> a crude sketch.
> 
> 1.  Expand "CAVEATS" sections in relevant Linux man-pages documents.
> 2.  Pursue N-document work with WG14.
> 3.  When WG14 has disposed of that N-document (and any descendants
>     thereof), update Linux man-pages documents as appropriate.
> 
> Joseph's almost certainly better placed than I to add a "step 1.5"
> such that Alex might pursue some course that would better prepare the
> ground for his step 2.  I haven't attempted revision of the C language
> standard myself, so I can't offer specific advice regarding how best to
> pursue such an objective.  I possess only notions of elemental
> principles regarding how democratic, consultative bodies of technical
> experts _should_ serve the public.
> 
> That _is_ what we're here for, right?

Yes.  Some more details:

I've obviously circulated this earlier within WG14, and CCd Keith and
Mark in case they could clarify historic details, or were otherwise
curious about/interested in the proposal.

Joseph stated opposition there (within WG14), and Keith Bostic suggested
that I could change the manual pages to document <memory.h>, and use
that to influence the public, in order to get to step 2.  (The exact
wording may differ.)  Indeed, I thought it was a great idea, as
<memory.h> is just as portable to POSIX-ish systems as <string.h>
(except for gnulib and Illumos gate, gnulib is CCd, so hopefully they
 address this portability issue).

> > I don't think it has anything to do with WG14 membership or anything
> > of the like? What am I missing?
> 
> See above regarding Alex's publicly circulated drafts and expressed
> plans.
> 
> > (*) Alex has a history of making opinonated changes like this to
> >     man-pages, such as removing references to older standards, and
> >     using a somewhat novel (to many) syntax for prototypes.
> 
> I concur with that assessment.  However, a person having a history of
> making opinionated changes is not sound grounds for evaluation of a
> technical proposal, especially if it's topically unrelated.
> 
> Preoccupying oneself with irrelevancies distracts from the conscientious
> execution of standards committee participation.

Thanks for the support!  :)


Have a lovely night!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Joseph Myers]

On Fri, 31 Jul 2026, G. Branden Robinson wrote:

> Occasionally, matters get relitigated because they had been wrongly
> decided.  I appreciate the trend since 2000 or so of Stroustrup (with

That's a plausible description of Alejandro's attempt to relitigate 
realloc with size 0, in order to reduce UB.  (Although in that case I 
think there have simply been too many changes, and so the semantics are 
irremediably confused regardless of any subsequent standard changes, and 
the best solution would involve a new function with a different name.)

I don't think it's a reasonable description for what are essentially 
stylistic matters, for anything as widely used as the header in which 
memcpy is declared or the NULL macro.  That's in "would have spelt creat 
with an e" territory - things that could have been better with hindsight 
but where the cost outweighs any possible benefit at this stage in the 
language's life.  "Avoiding UB" or "real user confusion" (in the case of 
strn*) are much better arguments than "slightly unaesthetic classification 
of functions into headers".

And I consider it an abuse of position to change man-pages to declare to 
users in general of C libraries on GNU/Linux that your standards proposal, 
at a very early stage (not even an N-document), is the One True Way of 
using the functions.  It would be more neutral to say in the man pages 
that "as of July 2026, one member of WG14 has proposed moving these 
functions to <memory.h> [reference]; this proposal has not yet been 
considered by WG14".  (I doubt the utility to users of describing proposed 
changes in man-pages at such an early stage, especially since the 
information would be long obsolete by the time those revisions of the 
pages make it into distributions, but it would at least more accurately 
reflect reality, and be vaguely neutral as long as you do it for 
*everyone's* open proposals, *including those you personally disagree 
with*, rather than privileging your own.)

-- 
Joseph S. Myers
josmyers@redhat.com

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3584 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 7346 bytes --]

Hi Joseph,

> Date: 2026-07-31 23:11:56+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> 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.
> 
> 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).

This is highly speculative.

If the official documentation says use <memory.h>, use <memory.h>.
Moreover, I've never seen anything saying <memory.h> is obsolescent.
It's been only implicitly obsolescent, and most programmers don't even
know <memory.h> exists at all.  FWIW, I've sometimes seen it in the
system headers, and eventually wondered why it was there, but nothing
else.  Thus, there's no contradicting information about it.

> Any reasonable change there would involve a new 
> header, say <strnpad.h> for strncpy and strncat,

I think that misses that strn*() are still relatively misunderstood.
It's only because they don't write that they aren't as dangerous.

But we would be much better with strprefix/suffix() and other related
functions in <string.h> to even further remove uses of strn*()
functions.

Moving the entirety of strn*() might be less urgent/important than
moving strncpy/cat(), but it'd still be good to move them.  They are all
about handling [[gnu::nonstring]]s.

> rather than resurrecting 
> a very old one.

I think the very old one is much better, because it can be used by
virtually all programs already, since it already is there in all systems
that matter, and already provides the functions were moving there.
Apart from documentation, there's no real change.

On the other hand, if we were adding a new header, it'd have to be
wrapped in #if __has_include(), and wouldn't be used until 10 years from
now or so.

> > 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.
> 
> It's inconsistent with how people have understood C ever since it was 
> standardized.  Changing the header memcpy is in is just as ridiculous at 
> this point as the proposal there once was to obsolesce NULL.

I disagree.  Obsolescing NULL is a deeply breaking change.
Standardizing an existing header file is just like standardizing an
existing function.  Nobody is saying <string.h> won't provide memcpy(3).
My proposal to C2y says that <string.h> includes <memory.h>, so nothing
changes.  All of the existing understanding remains valid (although less
preferred).

> > It wouldn't be reasonable to move strn*() to <memory.h>, and then leave
> > mem*() in <string.h>, of course.
> > 
> > Similarly, it wouldn't be reasonable to more strncpy/cat() to <memory.h>
> > and leave the rest of strn*() and all of mem*() in <string.h>.
> 
> 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.

Did you read my alx-0096 paper?  It shows how n2349 --which introduced
memccpy(3) in C23-- is full of UB in examples introduced as

	To avoid the risk of buffer overflow, the appropriate bound
	needs to be determined for each call and provided as an
	argument.

If memccpy(3) was standardized for reducing buffer overflows (which is
implied, but not very explicitly said in the paper), it's ironic that
the examples of how it's supposed to be used invoke UB.  If the author
of the paper can't avoid UB, you can guess it's a bomb as bad as
strncpy(3) once was.  And I'm not saying that memccpy(3) is bad, not
that strncpy(3) is bad.  I use strncpy(3) and know it's fine, and have
been recently shown that memccpy(3) is actually good for implementing
fgets(3).  But it's not a function for copying strings, and n2349 is the
ultimate proof.  It is just as bad as strncpy(3) if misused for copying
strings.

I'll paste here part of alx-0096, which clarifies how n2349 invokes UB.

        Reading N2349 further, one finds an example of copying with
        truncation:

                char *p = memccpy (d, s1, '\0', dsize);
                dsize -= (p - d - 1);
                memccpy (p - 1, s2, '\0', dsize);

        This is more prone to bugs than the case above, and more than
        strncpy(3).  Anyone suggesting to use this to improve safety
        compared to strncpy(3), please, please, explain to me how they
        think this can be safe in any way.

        In fact, the code above is completely bogus, because if the
        string is truncated, p will be NULL, and it invokes UB in
        line 2.  See how it was predictably prone to bugs?  :)

        At the bottom of the N2349 paper, there's a more correct --and
        also more worrying-- example of how memccpy(3) could be used for
        copying strings with truncation.  This shows how terrible
        memccpy(3) is for copying strings:

                char *p = memccpy (d, s1, '\0', dsize);
                if (p) {
                  --p;
                  p = memccpy (p, "/", '\0', dsize - (p - d));
                  if (p) {
                    --p;
                    p = memccpy (p, s2, '\0', dsize - (p - d));
                  }
                }
                if (!p)
                  d[dsize - 1] = '\0';

        I think I don't need to explain what can go wrong in such
        unreadable, brittle, and complex code.

	...

        Using a more suitable function --similar to POSIX's stpcpy(3)--,
        this could be written much more safely:

                char *p = d;
                char *e = d + dsize;
                p = stpecpy(p, e, s1);
                p = stpecpy(p, e, "/");
                p = stpecpy(p, e, s2);
                if (p == NULL)
                        goto trunc;  // The string was truncated

        Here's how stpecpy() can be implemented for this:

                char *
                stpecpy(char *dst, const char *end, const char *restrict src)
                {
                        ssize_t  dlen;

                        if (dst == NULL)
                                return NULL;

                        dlen = strtcpy(dst, src, end - dst);
                        if (dlen == -1)
                                return NULL;

                        return dst + dlen;
                }


Cheers,
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Collin Funk]

Joseph Myers <josmyers@redhat.com> writes:

> I'd rather we add a mandatory deprecation warning to memory.h in glibc.

I would be for this change, and am surprised it has not already been
done, to honest. The use of memory.h is a good indicator code hasn't
been touched since the 80s.

Collin

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Hi Collin,

> Date: 2026-07-31 16:48:38-0700
> From: Collin Funk <collin.funk1@gmail.com>
>
> Joseph Myers <josmyers@redhat.com> writes:
> 
> > I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> 
> I would be for this change, and am surprised it has not already been
> done, to honest. The use of memory.h is a good indicator code hasn't
> been touched since the 80s.

Or that it has been touched in 2026.  :)


Cheers,
Alex

> 
> Collin

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

Hi Joseph,

At 2026-07-31T23:28:19+0000, Joseph Myers wrote:
> And I consider it an abuse of position to change man-pages to declare
> to users in general of C libraries on GNU/Linux that your standards
> proposal, at a very early stage (not even an N-document), is the One
> True Way of using the functions.

I agree that there is a _potential_ moral hazard here.

> It would be more neutral to say in the man pages that "as of July
> 2026, one member of WG14 has proposed moving these functions to
> <memory.h> [reference]; this proposal has not yet been considered by
> WG14".  (I doubt the utility to users of describing proposed changes
> in man-pages at such an early stage, especially since the information
> would be long obsolete by the time those revisions of the pages make
> it into distributions, but it would at least more accurately reflect
> reality, and be vaguely neutral as long as you do it for *everyone's*
> open proposals, *including those you personally disagree with*, rather
> than privileging your own.)

I endorse this perspective.  Another thing Alex could do is gate such
readily-obsolescent stuff behind a *roff register so that it doesn't
format (or, if one uses soelim(1), even populate the document sources),
for _official releases_, but is still there for people pulling on Alex's
Git repository.

My interpretation of Alex's tactics is that he feels energetic about his
proposal, is willing to think it through carefully and advocate for
it--these are good things--and that he wants to get it in front of
domain experts and anneal it by fire before formally putting it before
WG14--_also_ a good thing!  In the meantime, he is the steward of a
platform that _is_ topically implicated.

Such a position _can_ be abused, but it also seems not quite fair to me
to expect him to stifle his advocacy in a _relevant_ forum.

Conventionally, what Alex faces is a potential conflict of interest.
There are a variety of ways to cope with those.  Foremost is disclosure
to others of the potential conflict.  That's such an important factor
that I'd say it's 90% of the battle.  Most of the time when people
resist disclosing potential CofIs it's because they're self-dealing,
they know it, and realize that disclosure would be self-incriminating.

There is another tier to the issue, and its recourse is recusal.  We
most often see this in the context of arbitration or in the judiciary.

However, Alex is not situated as a judge or gatekeeper here.  To WG14,
and to C library maintainers, he is an advocate.  Has Alex rejected any
proposed patches to the Linux man-pages along similar lines as his own
advocacy?  That would be gatekeeping.

Alex might consider deputizing a fellow maintainer to handle updates to
portions of man pages where he has, or expects to have, business before
WG14.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Hi Collin,

> Date: 2026-08-01 01:52:37+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi Collin,
> 
> > Date: 2026-07-31 16:48:38-0700
> > From: Collin Funk <collin.funk1@gmail.com>
> >
> > Joseph Myers <josmyers@redhat.com> writes:
> > 
> > > I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> > 
> > I would be for this change, and am surprised it has not already been
> > done, to honest. The use of memory.h is a good indicator code hasn't
> > been touched since the 80s.
> 
> Or that it has been touched in 2026.  :)

FWIW, a Debian code search shows 8.9k entries of 'include\s*<memory.h>',
including for example in utils-linux, which is well maintained code.

That breaking change is well beyond what I think can be possibly done.


Cheers,
Alex


> 
> Cheers,
> Alex
> 
> > 
> > Collin
> 
> -- 
> <https://www.alejandro-colomar.es>



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

Hi Branden,

> Date: 2026-07-31 18:57:47-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Joseph,
> 
> At 2026-07-31T23:28:19+0000, Joseph Myers wrote:
> > And I consider it an abuse of position to change man-pages to declare
> > to users in general of C libraries on GNU/Linux that your standards
> > proposal, at a very early stage (not even an N-document), is the One
> > True Way of using the functions.
> 
> I agree that there is a _potential_ moral hazard here.
> 
> > It would be more neutral to say in the man pages that "as of July
> > 2026, one member of WG14 has proposed moving these functions to
> > <memory.h> [reference]; this proposal has not yet been considered by
> > WG14".  (I doubt the utility to users of describing proposed changes
> > in man-pages at such an early stage, especially since the information
> > would be long obsolete by the time those revisions of the pages make
> > it into distributions, but it would at least more accurately reflect
> > reality, and be vaguely neutral as long as you do it for *everyone's*
> > open proposals, *including those you personally disagree with*, rather
> > than privileging your own.)
> 
> I endorse this perspective.  Another thing Alex could do is gate such
> readily-obsolescent stuff behind a *roff register so that it doesn't
> format (or, if one uses soelim(1), even populate the document sources),
> for _official releases_, but is still there for people pulling on Alex's
> Git repository.
> 
> My interpretation of Alex's tactics is that he feels energetic about his
> proposal, is willing to think it through carefully and advocate for
> it--these are good things--and that he wants to get it in front of
> domain experts and anneal it by fire before formally putting it before
> WG14--_also_ a good thing!  In the meantime, he is the steward of a
> platform that _is_ topically implicated.
> 
> Such a position _can_ be abused, but it also seems not quite fair to me
> to expect him to stifle his advocacy in a _relevant_ forum.
> 
> Conventionally, what Alex faces is a potential conflict of interest.
> There are a variety of ways to cope with those.  Foremost is disclosure
> to others of the potential conflict.  That's such an important factor
> that I'd say it's 90% of the battle.  Most of the time when people
> resist disclosing potential CofIs it's because they're self-dealing,
> they know it, and realize that disclosure would be self-incriminating.

Indeed.  While I haven't explicitly mentioned CofI, I haven't hidden it
either, and have mentioned all the relevant information.  If I haven't
merged this single-handedly, it's precisely because I think there could
be some, and want to get feedback.


Cheers,
Alex

> 
> There is another tier to the issue, and its recourse is recusal.  We
> most often see this in the context of arbitration or in the judiciary.
> 
> However, Alex is not situated as a judge or gatekeeper here.  To WG14,
> and to C library maintainers, he is an advocate.  Has Alex rejected any
> proposed patches to the Linux man-pages along similar lines as his own
> advocacy?  That would be gatekeeping.
> 
> Alex might consider deputizing a fellow maintainer to handle updates to
> portions of man pages where he has, or expects to have, business before
> WG14.
> 
> Regards,
> Branden



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Hi Sam,

> Date: 2026-08-01 00:19:03+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> > Date: 2026-07-31 22:54:27+0100
> > From: Sam James <sam@gentoo.org>
> >
[...]
> > People want it to reflect what the standard says.
> 
> And it still does.

Hmmm, this has implications.  The functions that are non-standard, can
be changed as of now, because, well, there's no standard saying
otherwise.

Maybe that's a good move.  A commit now changing the following functions
the be documented as provided by <memory.h>, without any mentions to
<string.h>, simply because there's no standard mandating otherwise:

	-  strndupa(3)
	-  mempcpy(3)
	-  memrchr(3)
	-  memmem(3)
	-  memfrob(3)

Which is a nice introduction for this header file.

Then we can leave discussion of the standard functions for later.
If what the standard says is the problem, let's focus on what it doesn't
say.


Cheers,
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

They've been provided there since forever, and that's a more appropriate
header.

While it would be good to document the standard functions also as
provided by <memory.h>, that's more controversial, and is still being
litigated.

Link: <https://lore.kernel.org/linux-man/am0RdPxvbIYUKAL-@devuan/T/#t>
Cc: Sam James <sam@gentoo.org>
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Joseph Myers <josmyers@redhat.com>
Cc: Keith Bostic <keith@bostic.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: Serge Hallyn <serge@hallyn.com>
Cc: Iker Pedrosa <ipedrosa@redhat.com>
Cc: Evgeny Grin <k2k@drgrin.dev>
Cc: Kees Cook <keescook@chromium.org>
Cc: bug-gnulib@gnu.org
Cc: libc-alpha@sourceware.org
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---

Hi!

Here's a less ambitious change.  It's not that I don't want to pursue
the other one, but that this one will likely pass more quickly.

This only changes documentation for non-standard functions, where the
argument that the standard says XXX is now irrelevant.


Have a lovely night!
Alex

 man/man3/memfrob.3 | 2 +-
 man/man3/memmem.3  | 2 +-
 man/man3/mempcpy.3 | 2 +-
 man/man3/memrchr.3 | 2 +-
 man/man3/strdupa.3 | 4 ++++
 5 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/man/man3/memfrob.3 b/man/man3/memfrob.3
index ee41da0ced7b..ad736949002c 100644
--- a/man/man3/memfrob.3
+++ b/man/man3/memfrob.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "             /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *memfrob(" "size_t n;"
 .BI "              void " s [ n "], size_t " n );
diff --git a/man/man3/memmem.3 b/man/man3/memmem.3
index 13fd8b7cea7b..d0f99e6d577d 100644
--- a/man/man3/memmem.3
+++ b/man/man3/memmem.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "         /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *memmem(" "size_t hsize, size_t nsize;"
 .BI "             const void " haystack [ hsize "], size_t " hsize ,
diff --git a/man/man3/mempcpy.3 b/man/man3/mempcpy.3
index 012e6326dd00..4598be5d7bc2 100644
--- a/man/man3/mempcpy.3
+++ b/man/man3/mempcpy.3
@@ -14,7 +14,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "         /* See feature_test_macros(7) */"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR "void *mempcpy(" "size_t n;"
 .BI "              void " dest "[restrict " n "], const void " src "[restrict " n ],
diff --git a/man/man3/memrchr.3 b/man/man3/memrchr.3
index 6e49defc5e4a..fe2841147f05 100644
--- a/man/man3/memrchr.3
+++ b/man/man3/memrchr.3
@@ -13,7 +13,7 @@ .SH LIBRARY
 .SH SYNOPSIS
 .nf
 .BR #define\~_GNU_SOURCE "  // See feature_test_macros(7)"
-.B #include <string.h>
+.B #include <memory.h>
 .P
 .BR void\~*memrchr( size_t\~n;
 .BI "              const void " s [ n "], int " c ", size_t " n );
diff --git a/man/man3/strdupa.3 b/man/man3/strdupa.3
index 63b12c83e9ec..412eec9f3491 100644
--- a/man/man3/strdupa.3
+++ b/man/man3/strdupa.3
@@ -16,6 +16,10 @@ .SH SYNOPSIS
 .B #include <string.h>
 .P
 .BI "char *strdupa(const char *" s );
+.P
+.BR "#define _GNU_SOURCE" "  /* See feature_test_macros(7) */"
+.B #include <memory.h>
+.P
 .BR "char *strndupa(" "size_t n;"
 .BI "              const char " s [ n "], size_t " n );
 .fi

base-commit: 8152eb52d9a92f02c14e843545acec7ee1946479
-- 
2.53.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]