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

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Sam,

> Date: 2026-07-31 22:59:47+0100
> From: Sam James <sam@gentoo.org>
>
> (*) 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 think this comment deserves a well thought response.

"Opinionated" is your subjective knee-jerk way of saying it.  I don't
agree with it.

I'd say I have a history of making changes based on thorough revision of
history and technical merits, even when that research is contrary to
decades (or half-centuries) of common practice, and possibly to
current or withdrawn standards.

In this case, and I don't mean this specific patch set, but the years-
long revision of string documentation that I've been carrying out, we
have a conflict between the design and correct use of string and memory
functions, and their common use today.

The functions that are most subject to this conflict are strncpy(3),
strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
affected, and the rest of mem*() minorly affected.

They were originally designed for a specific use case for which they
were great.  This knowledge has been lost in time, and I've been working
to recover that knowledge.

Precisely because of standards and other documentation that isn't
written with the level of care that I have, we have decades of misuses
of strncpy(3) and strncat(3).

Moreover, it's in other places that you should be complaining about.
GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
which we could very well call opinionated, and I haven't seen anyone
reporting them as bogus before I did.  Those diagnostics have not been
considered opinionated, just because they follow mainstream (bogus)
usage of these functions, but they are indeed forcing an opinion of how
these functions should be used over other uses that may be more uncommon
but which are actually the original and correct uses of these functions.
<https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>

It's curious that you called the GCC diagnostic "heuristics" instead of
"opinionated".  There's nothing about heuristics there.  It's just an
enforcement of an (incorrect) opinion about how these functions should
be used.

And since C23, we're seeing that the same story is repeating with
memccpy(3), which was once a niche function that was great for
implementing fgets(3), and now is misused by everyone and their dog for
copying strings with truncation.

I have spent probably more time than anyone in the last 5 years
researching about string handling, and have proven the correctness of my
research in the shadow-utils project, where most of my work has been in
revising string and memory handling code.  I've fixed uncountable subtle
bugs in such code, and have made the resulting code actually readable.
And the number of accidental regressions is minimal (IIRC, one or two
regressions related to string and memory handling, in all that time, and
not too dangerous).

Thus, I think it is my responsibility, as maintainer of the
documentation project most read by C programmers, to let our audience
learn what I've learnt in these years, and allow them to write safe
string- and memory-handling code.

It is thanks to this years-long research that I've been able to gather
important knowledge from people like Mark Harris, Doug McIlroy, Branden,
and many others, who hold knowledge that few other programmers possess,
and spread it to the world.

I'd consider it a negligence to do the easy thing and follow what
standards say, or what most programmers do, because that's what has led
us to the well-known mistakes that C programmers make.

FWIW, regarding the possible conflict of interest that was mentioned
yesterday, I'll say that I don't get paid for my contributions to ISO C
as a member of WG14.  There's no benefit to me other than public
recognition.  I'll also disclose the exact quantity that I've been paid
for maintaining the Linux man-pages project:

	110 kUSD in 2025 (from 5 sponsors)
	75 kUSD in 2026 (from 3 sponsors)

I'm convinced that that doesn't have any effects in my decisions here,
as I've had a consistent record of decisions well before I had any
economic benefits from maintaining this project.  None of those sponsors
have expressed any interest in favour of these decisions (nor against).

I'll rumiate a bit more on these patches, and probably make minor
changes to them, but the essence of documenting <memory.h> for all of
mem*() and strn*() in SYNOPSIS is most likely to be eventually merged.
I'll be careful to document what the standards say in a way that isn't
confusing to users, and also in general will try to document it in a way
that is positive for our audience --even if some of that audience may
have knee-jerk reactions, like you are having at the moment--.  I have
also received very positive feedback for other changes for which some
people have noisily had knee-jerk reactions.  I believe it is my duty
as maintainer of this project to do this change.


Have a lovely day!
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

[Alejandro Colomar]

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

> Date: 2026-08-01 14:01:39+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi Sam,
> 
> > Date: 2026-07-31 22:59:47+0100
> > From: Sam James <sam@gentoo.org>
> >
> > (*) 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 think this comment deserves a well thought response.
> 
> "Opinionated" is your subjective knee-jerk way of saying it.  I don't
> agree with it.
> 
> I'd say I have a history of making changes based on thorough revision of
> history and technical merits, even when that research is contrary to
> decades (or half-centuries) of common practice, and possibly to
> current or withdrawn standards.
> 
> In this case, and I don't mean this specific patch set, but the years-
> long revision of string documentation that I've been carrying out, we
> have a conflict between the design and correct use of string and memory
> functions, and their common use today.
> 
> The functions that are most subject to this conflict are strncpy(3),
> strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
> affected, and the rest of mem*() minorly affected.
> 
> They were originally designed for a specific use case for which they
> were great.  This knowledge has been lost in time, and I've been working
> to recover that knowledge.
> 
> Precisely because of standards and other documentation that isn't
> written with the level of care that I have, we have decades of misuses
> of strncpy(3) and strncat(3).
> 
> Moreover, it's in other places that you should be complaining about.
> GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
> which we could very well call opinionated, and I haven't seen anyone
> reporting them as bogus before I did.  Those diagnostics have not been
> considered opinionated, just because they follow mainstream (bogus)
> usage of these functions, but they are indeed forcing an opinion of how
> these functions should be used over other uses that may be more uncommon
> but which are actually the original and correct uses of these functions.
> <https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>
> 
> It's curious that you called the GCC diagnostic "heuristics" instead of
> "opinionated".  There's nothing about heuristics there.  It's just an
> enforcement of an (incorrect) opinion about how these functions should
> be used.
> 
> And since C23, we're seeing that the same story is repeating with
> memccpy(3), which was once a niche function that was great for
> implementing fgets(3), and now is misused by everyone and their dog for
> copying strings with truncation.
> 
> I have spent probably more time than anyone in the last 5 years
> researching about string handling, and have proven the correctness of my
> research in the shadow-utils project, where most of my work has been in
> revising string and memory handling code.  I've fixed uncountable subtle
> bugs in such code, and have made the resulting code actually readable.
> And the number of accidental regressions is minimal (IIRC, one or two
> regressions related to string and memory handling, in all that time, and
> not too dangerous).
> 
> Thus, I think it is my responsibility, as maintainer of the
> documentation project most read by C programmers, to let our audience
> learn what I've learnt in these years, and allow them to write safe
> string- and memory-handling code.
> 
> It is thanks to this years-long research that I've been able to gather
> important knowledge from people like Mark Harris, Doug McIlroy, Branden,
> and many others, who hold knowledge that few other programmers possess,
> and spread it to the world.
> 
> I'd consider it a negligence to do the easy thing and follow what
> standards say, or what most programmers do, because that's what has led
> us to the well-known mistakes that C programmers make.
> 
> FWIW, regarding the possible conflict of interest that was mentioned
> yesterday, I'll say that I don't get paid for my contributions to ISO C
> as a member of WG14.  There's no benefit to me other than public
> recognition.  I'll also disclose the exact quantity that I've been paid
> for maintaining the Linux man-pages project:
> 
> 	110 kUSD in 2025 (from 5 sponsors)
> 	75 kUSD in 2026 (from 3 sponsors)
> 
> I'm convinced that that doesn't have any effects in my decisions here,
> as I've had a consistent record of decisions well before I had any
> economic benefits from maintaining this project.  None of those sponsors
> have expressed any interest in favour of these decisions (nor against).
> 
> I'll rumiate a bit more on these patches, and probably make minor
> changes to them, but the essence of documenting <memory.h> for all of
> mem*() and strn*() in SYNOPSIS is most likely to be eventually merged.
> I'll be careful to document what the standards say in a way that isn't
> confusing to users, and also in general will try to document it in a way
> that is positive for our audience --even if some of that audience may
> have knee-jerk reactions, like you are having at the moment--.  I have
> also received very positive feedback for other changes for which some
> people have noisily had knee-jerk reactions.  I believe it is my duty
> as maintainer of this project to do this change.
> 
> 
> Have a lovely day!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>

And of course, I'm not dismissing that I may make mistakes in early
drafts of decisions, and sometimes take decisions before thinking
enough, but I have a good record of revising my own decisions when they
were mistaken.


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

[Douglas McIlroy]

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

Yes, this is a property of the language, not a peculiar deficiency of the
<string.h> functions. As I see it, patching up perceived deficiencies of the
functions adds complexity to the language definition and to the task of
code-reading, with little real benefit.

Doug

On Fri, Jul 31, 2026 at 7:45 PM Alejandro Colomar <alx@kernel.org> wrote:
>
> 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>

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: 5928 bytes --]

Hi Branden,

> Date: 2026-07-31 18:32:53-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
[...]
> 
> 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?

As I said, I think it's the other way around.  <memory.h> is great,
because there's no public record of it being obsolescent.  It has only
been _implicitly_ obsolescent, but the fact that it has remained without
much attention make it a good candidate.  Just as much as it was done
with memccpy(3) in C23, except that memccpy(3) was brought back for
bogus reasons (it's as bad as strncpy(3) for the purpose it was
standardized).

<memory.h> is already available in all systems that matter, so programs
can start using it today, as opposed to <stdmem.h>, which could only be
used relied upon around 2036 --for the early adopters--.  If we didn't
have the old <memory.h> header, I'd certainly prefer <stdmem.h>, but for
these reasons, <memory.h> seems the way to go.

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

I strongly disagree.

And a cordon sanitaire wouldn't help.  That's the approach that n2349
took, and it was bogus.  It's not a matter of saying "these two
functions are bad".  It's a matter of learning what each function is
good for.  And all of mem*() and strn*() are good for memory handling
and nonstring handling (which can be considered a specific case of
memory handling).  Thus, all of them belong in <memory.h>.

A cordon sanitaire will continue to ignore the fact that the problem is
not in the functions themselves, but in how users think of these
functions.  I expect in 10 years from now, if we don't do anything,
people will notice the same problems in memccpy(3) that we now attribute
to strncpy(3).

Just look at all the garbage that people have written with memccpy(3)
after it was standardized in C23.  A Debian code search will suffice to
show the brain damage.  Or you can just look at n2349, the paper that
proposed it for its standardization, which already has UB in the
examples of how it can be used for copying strings.  It's all just too
ironic.

Let's make it easy to understand these functions, and avoid blaming any
functions for what really is our lack of understanding.

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

+1

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

+1

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

For the reasons above, <memory.h> is better.

About the third header, I originally thought that, and in alx-0097
I wrote about adding a <nonstring.h> header.  However, the more I think
about it, the more I think these are just fine in <memory.h>.  The Linux
kernel for example, renamed strncpy(3) to strtomem_pad() --and as
discussed within WG14, the _pad in that name is redundant, so it could
perfectly have been called strtomem()--.  This shows that these
functions are not as unrelated to <memory.h> as their current names
suggest.

This, combined with the fact that they are already available through
<memory.h>, makes me think that we should just put them in <memory.h>,
which would lead people to think about a binary distinction between
<string.h> for string-only, and <memory.h> for memory stuff that doesn't
handle strings.


Have a lovely day!
Alex

> 
> Regards,
> Branden
> 
> [1] https://www.freedos.org/books/cprogramming/part8/



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

[Christopher Bazley]

Hi,

On Sat, Aug 1, 2026 at 12:32 AM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> 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.

I have been reluctant to stick my oar into this argument, but the
proposal above is the best I have seen so far.  The trouble with
Alex's assertion that the strn... functions are not string functions
and therefore must be memory functions is that it strikes me as a
false dichotomy.  I understand why he makes that claim, and I
understand the damage the confusion has caused, but I do not find it
entirely plausible given that strncat appends to a string and strncpy
can consume one.  I also understand the deep attraction of righting
past wrongs, but it seems to me that, in this instance, the past was
not so satisfactory either.

I am skeptical that many users will include header files that did not
exist before C2Y, but it may be worth trying. I do not think the
proposal to restore <memory.h> would be much better: it does not exist
on many platforms. If we are going to introduce a new separation, let
us make it a good one.

Christopher

Re: on the irresponsibility of pursuing C language reform

[Sam James]

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

Alejandro Colomar <alx@kernel.org> writes:

> Hi Sam,
>
>> Date: 2026-07-31 22:59:47+0100
>> From: Sam James <sam@gentoo.org>
>>
>> (*) 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 think this comment deserves a well thought response.
>
> "Opinionated" is your subjective knee-jerk way of saying it.  I don't
> agree with it.

I don't consider it kneejerk. It's an opinion I've formed over the
years. You're of course free to disagre with it.

>
> I'd say I have a history of making changes based on thorough revision of
> history and technical merits, even when that research is contrary to
> decades (or half-centuries) of common practice, and possibly to
> current or withdrawn standards.

The primary issue I have is that I don't often see you change your mind
or acknowledge that being the man-pages maintainer is a privileged
position, or separate your desires from the maintainership role.

When I'm acting in a maintainer role, I often take changes I don't
particularly agree with if they're technically sound and there's broad
consensus for them. I think many do.

>
> In this case, and I don't mean this specific patch set, but the years-
> long revision of string documentation that I've been carrying out, we
> have a conflict between the design and correct use of string and memory
> functions, and their common use today.
>

Yes, I don't dispute that the terminology is poor.

> The functions that are most subject to this conflict are strncpy(3),
> strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
> affected, and the rest of mem*() minorly affected.
>
> They were originally designed for a specific use case for which they
> were great.  This knowledge has been lost in time, and I've been working
> to recover that knowledge.
>
> Precisely because of standards and other documentation that isn't
> written with the level of care that I have, we have decades of misuses
> of strncpy(3) and strncat(3).
>
> Moreover, it's in other places that you should be complaining about.

I do complain about those, and we finally got some consensus on the GCC
side on not warning about a bunch of them by default, even.

> GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
> which we could very well call opinionated, and I haven't seen anyone
> reporting them as bogus before I did.  Those diagnostics have not been
> considered opinionated, just because they follow mainstream (bogus)
> usage of these functions, but they are indeed forcing an opinion of how
> these functions should be used over other uses that may be more uncommon
> but which are actually the original and correct uses of these functions.
> <https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>
>
> It's curious that you called the GCC diagnostic "heuristics" instead of
> "opinionated".  There's nothing about heuristics there.  It's just an
> enforcement of an (incorrect) opinion about how these functions should
> be used.

The warnings are both opinionated and heuristics-based. I'm not sure how
you could read the comment you linked to as somehow an endorsement of
the status quo, I've been quite vocal about changing it elsewhere too?

>
> And since C23, we're seeing that the same story is repeating with
> memccpy(3), which was once a niche function that was great for
> implementing fgets(3), and now is misused by everyone and their dog for
> copying strings with truncation.
>
> I have spent probably more time than anyone in the last 5 years
> researching about string handling, and have proven the correctness of my
> research in the shadow-utils project, where most of my work has been in
> revising string and memory handling code.  I've fixed uncountable subtle
> bugs in such code, and have made the resulting code actually readable.
> And the number of accidental regressions is minimal (IIRC, one or two
> regressions related to string and memory handling, in all that time, and
> not too dangerous).
>
> Thus, I think it is my responsibility, as maintainer of the
> documentation project most read by C programmers, to let our audience
> learn what I've learnt in these years, and allow them to write safe
> string- and memory-handling code.
>
> It is thanks to this years-long research that I've been able to gather
> important knowledge from people like Mark Harris, Doug McIlroy, Branden,
> and many others, who hold knowledge that few other programmers possess,
> and spread it to the world.
>
> I'd consider it a negligence to do the easy thing and follow what
> standards say, or what most programmers do, because that's what has led
> us to the well-known mistakes that C programmers make.
>
> FWIW, regarding the possible conflict of interest that was mentioned
> yesterday, I'll say that I don't get paid for my contributions to ISO C
> as a member of WG14.  There's no benefit to me other than public
> recognition.  I'll also disclose the exact quantity that I've been paid
> for maintaining the Linux man-pages project:

You can have a conflict of interest in responsibliity without money
being involved. In fact, I have never believed you were influenced by
money, just that you let your personal opinions unduly influence your
decisions in modifying man-pages, even when consensus seems against it.

>
> 	110 kUSD in 2025 (from 5 sponsors)
> 	75 kUSD in 2026 (from 3 sponsors)
>
> I'm convinced that that doesn't have any effects in my decisions here,
> as I've had a consistent record of decisions well before I had any
> economic benefits from maintaining this project.  None of those sponsors
> have expressed any interest in favour of these decisions (nor against).
>
> I'll rumiate a bit more on these patches, and probably make minor
> changes to them, but the essence of documenting <memory.h> for all of
> mem*() and strn*() in SYNOPSIS is most likely to be eventually merged.
> I'll be careful to document what the standards say in a way that isn't
> confusing to users, and also in general will try to document it in a way
> that is positive for our audience --even if some of that audience may
> have knee-jerk reactions, like you are having at the moment--.  I have
> also received very positive feedback for other changes for which some
> people have noisily had knee-jerk reactions.  I believe it is my duty
> as maintainer of this project to do this change.
>

Please stop saying I'm having a kneejerk reaction. I haven't even yet
commented on the substance of the changes, I've just commented on how I
don't believe in making changes through man-pages like this.

>
> Have a lovely day!
> Alex

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>

[Sam James]

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

Alejandro Colomar <alx@kernel.org> writes:

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

OK, that's useful behaviour. I wasn't aware it accepted a list of
headers that would provide it.

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

I think we have different views on the purpose of man-pages and users'
expectations of them.

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

Yes, we got there in the end, but it was very disruptive, and caused a
lot of pain. I am not sure the right lessons have been learned from it.

>
>> People want it to reflect what the standard says.
>
> And it still does.
>
>
> Have a lovely night!
> Alex

[-- 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: 4720 bytes --]

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

> Hi Sam,

Hi Branden,

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

Ah, I see. Thanks for explaining.

To clarify then: I have no issue with Alex advocating changes. I just
have an issue with man-pages being used regularly as a vehicle for that.

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

I agree this is more productive, thanks for setting it out.

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

What I mean is that I didn't take Joseph's comments to be an objection
to Alex's WG14 membership or anything of the sort, just that man-pages
isn't an appropriate vehicle for it. In any case, that's my position
even if I misunderstood Joseph's.

>
>> (*) 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 your thoughtful email. I found it helpful!

> Regards,
> Branden

sam

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

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Sam,

> Date: 2026-08-01 15:38:42+0100
> From: Sam James <sam@gentoo.org>
>
[...]
> >
> > I'd say I have a history of making changes based on thorough revision of
> > history and technical merits, even when that research is contrary to
> > decades (or half-centuries) of common practice, and possibly to
> > current or withdrawn standards.
> 
> The primary issue I have is that I don't often see you change your mind

I do quite frequently, actually.  Most recently, this week:

<https://lore.kernel.org/linux-man/CAMdZqKEEncWS64BUL1qa0SfcNUaNA9XRBPWTpHPB==N3VV_Nzg@mail.gmail.com/>
<https://lore.kernel.org/linux-man/amupqzN_X57Du4AJ@devuan/>

	> Date: Thu, 30 Jul 2026 21:51:16 +0200
	> From: Alejandro Colomar <alx@kernel.org>
	>
	> > Date: Thu, 30 Jul 2026 10:58:26 -0700
	> > From: Mark Harris <mark.hsj@gmail.com>
	> >
	> > It seems like you've already made up your mind that memccpy()
	> > is bad and are now just looking to justify that decision.
	>
	> Not necessarily.  I can be convinced with good arguments.  :-)
	>
	...
	> Agreed; there are use cases where memccpy(3) is preferrable.
	> You've convinced me.  :)

There are many other cases about cases where I had a strong opinion, and
people that are currently in CC have changed my mind.

Even you've changed my mind a few times, even if you don't remember or
didn't realize.

> or acknowledge that being the man-pages maintainer is a privileged
> position,

It's certainly a privileged position.  Just like maintainer of GCC, or
of Clang, or any other core project of most systems.  I acknowledge
this, and I believe I've acknowledged this before, implicitly and
explicitly.

> or separate your desires from the maintainership role.

My only desires are making it easy to allow programmers to write good
programs.  I believe that's my main responsibility as maintainer of this
project, and in general, the task of any good documentation.

> When I'm acting in a maintainer role, I often take changes I don't
> particularly agree with if they're technically sound and there's broad
> consensus for them. I think many do.

I also do often (and you probably don't notice, because you're not part
of this project, and are not here to observe every change).  But
sometimes, I must make decisions that some people --no matter how
important-- may disagree with.  I might be wrong, and I'll certainly
re-think about them after-the-fact, but this is one of them.

> > In this case, and I don't mean this specific patch set, but the years-
> > long revision of string documentation that I've been carrying out, we
> > have a conflict between the design and correct use of string and memory
> > functions, and their common use today.
> >
> 
> Yes, I don't dispute that the terminology is poor.

It's not only a matter of terminology.  And in fact, I thing the
terminology could be acceptable (not ideal, though).

> > The functions that are most subject to this conflict are strncpy(3),
> > strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
> > affected, and the rest of mem*() minorly affected.
> >
> > They were originally designed for a specific use case for which they
> > were great.  This knowledge has been lost in time, and I've been working
> > to recover that knowledge.
> >
> > Precisely because of standards and other documentation that isn't
> > written with the level of care that I have, we have decades of misuses
> > of strncpy(3) and strncat(3).
> >
> > Moreover, it's in other places that you should be complaining about.
> 
> I do complain about those, and we finally got some consensus on the GCC
> side on not warning about a bunch of them by default, even.

What do you mean?  And why have I not been CCed in such discussions,
after being the original reporter of the problems?  That kind of issue
management is certainly worse than what we're discussing here.

I believe that even though I may disagree with others, it's good to hear
their opinions, no matter how convinced I am that they're wrong, and no
matter how much they'll blame me for taking bad decisions.  Feedback is
(almost) always good, even when it's negative.

What exact changes have consensus in GCC?  How can there be consensus if
you haven't CCed the relevant people (including me)?

In any case, I guess it's good if GCC will improve.

> > GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
> > which we could very well call opinionated, and I haven't seen anyone
> > reporting them as bogus before I did.  Those diagnostics have not been
> > considered opinionated, just because they follow mainstream (bogus)
> > usage of these functions, but they are indeed forcing an opinion of how
> > these functions should be used over other uses that may be more uncommon
> > but which are actually the original and correct uses of these functions.
> > <https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>
> >
> > It's curious that you called the GCC diagnostic "heuristics" instead of
> > "opinionated".  There's nothing about heuristics there.  It's just an
> > enforcement of an (incorrect) opinion about how these functions should
> > be used.
> 
> The warnings are both opinionated

Thanks!

> and heuristics-based. I'm not sure how
> you could read the comment you linked to as somehow an endorsement of
> the status quo,

I don't read it as an endorsement of the status-quo.  Just a diminishing
of the fact that GCC maintainers, just like every other project, have
opinions --sometimes, like here, wrong opinions--, and they affect
other programmers that try to write good code.

> I've been quite vocal about changing it elsewhere too?

I'm not aware of anything that has not me in CC; sorry.

> > And since C23, we're seeing that the same story is repeating with
> > memccpy(3), which was once a niche function that was great for
> > implementing fgets(3), and now is misused by everyone and their dog for
> > copying strings with truncation.
> >
> > I have spent probably more time than anyone in the last 5 years
> > researching about string handling, and have proven the correctness of my
> > research in the shadow-utils project, where most of my work has been in
> > revising string and memory handling code.  I've fixed uncountable subtle
> > bugs in such code, and have made the resulting code actually readable.
> > And the number of accidental regressions is minimal (IIRC, one or two
> > regressions related to string and memory handling, in all that time, and
> > not too dangerous).
> >
> > Thus, I think it is my responsibility, as maintainer of the
> > documentation project most read by C programmers, to let our audience
> > learn what I've learnt in these years, and allow them to write safe
> > string- and memory-handling code.
> >
> > It is thanks to this years-long research that I've been able to gather
> > important knowledge from people like Mark Harris, Doug McIlroy, Branden,
> > and many others, who hold knowledge that few other programmers possess,
> > and spread it to the world.
> >
> > I'd consider it a negligence to do the easy thing and follow what
> > standards say, or what most programmers do, because that's what has led
> > us to the well-known mistakes that C programmers make.
> >
> > FWIW, regarding the possible conflict of interest that was mentioned
> > yesterday, I'll say that I don't get paid for my contributions to ISO C
> > as a member of WG14.  There's no benefit to me other than public
> > recognition.  I'll also disclose the exact quantity that I've been paid
> > for maintaining the Linux man-pages project:
[...]
> In fact, I have never believed you were influenced by
> money,

Thanks!

> just that you let your personal opinions unduly influence your
> decisions in modifying man-pages,

I've done a lot of research and hearing experts to reach this
decision(s).  I believe it's not just an opinion, but a technical
decision even if a controversial one.

[reordered]
> You can have a conflict of interest in responsibliity without money
> being involved.

I'll continue to think about this and other concerns, and may change my
mind later.  At this moment, I believe I'm taking a technical decision
after hearing enough experts and researching the topic more than anyone
for several years.

> even when consensus seems against it.

I wouldn't say consensus against; just a vocal number of people that
disagree.  I wouldn't say there's consensus in favour, of course, but
when there's no consensus, I have to take the last decision.  Most of
the time, that last decision means not doing anything, but in this case,
it's different.


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

[Alejandro Colomar]

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

Hi Chris,

> Date: 2026-08-01 15:26:05+0100
> From: Christopher Bazley <chris.bazley.wg14@gmail.com>
>
> On Sat, Aug 1, 2026 at 12:32 AM G. Branden Robinson
> <g.branden.robinson@gmail.com> wrote:
> > 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.
> 
> I have been reluctant to stick my oar into this argument, but the
> proposal above is the best I have seen so far.



> The trouble with
> Alex's assertion that the strn... functions are not string functions
> and therefore must be memory functions is that it strikes me as a
> false dichotomy.  I understand why he makes that claim, and I
> understand the damage the confusion has caused, but I do not find it
> entirely plausible given that strncat appends to a string and strncpy
> can consume one.

You and I have actually the same opinion of strn*() functions.  We only
differ in the wording, and it was likely my fault for using wording that
isn't the most precise.

I've said in the past that strn*() functions are not string functions,
and as you say this is not exactly true, since indeed, strncat(3)
produces one, and strncpy(3) may consume one.

I believe I should have said --and my most recent messages are in that
line-- that strncpy(3) and strncat(3) are not _string-only_ functions.
They have arguments that are not strings, and that's what makes them
different from the rest of <string.h>.  All of the str*() functions that
are not strn*() functions --thus, the str[^n]*() functions, as Branden
called them, using regex syntax-- share this in common: they handle
strings exclusively, in all their arguments (except of course, the
integer ones); that is, it is UB if a nonstring is passed, and when they
create output, that output is a string.

The following functions, all *require* strings, and *unconditionally*
produce strings (if they produce anything):

   Copy
     strcpy(3)
     stpcpy(3)

   Catenate
     strcat(3)

   Duplicate
     strdup(3)
     strdupa(3)

   Compare
     streq(3)
     strcmp(3)
     strcasecmp(3)
     strcoll(3)
     strverscmp(3)

   Search
     strlen(3)
     strnul(3)
     strchrnul(3)
     strchr(3)
     strrchr(3)
     strpbrk(3)
     strstr(3)
     strcasestr(3)
     strspn(3)
     strcspn(3)

   Separate
     strsep(3)
     strtok(3)

   Others
     strxfrm(3)

This is the entire set of str[^n]*() functions from <string.h>, as
documented in string(3).  The rest of functions are strn*() and mem*(),
and they share something in common: they may take nonstrings and/or may
produce nonstrings.

In fact, mempcpy(3) is not really a memory function like the other
mem*() functions.  mempcpy(3) is specifically useful for handling
nonstrings (and is also useful for producing strings out of those
nonstrings later).  There's no clear cut in these functions, and you may
claim that mempcpy(3) belongs more in <stdstrn.h> or <string.h> than in
<memory.h>, if only for the kind of code you'd use it for.

The only clear cut is that some functions require and produce strings
exclusively, and others may not necessarily do so (even if they may
sometimes do so).

> I also understand the deep attraction of righting
> past wrongs, but it seems to me that, in this instance, the past was
> not so satisfactory either.
> 
> I am skeptical that many users will include header files that did not
> exist before C2Y, but it may be worth trying. I do not think the
> proposal to restore <memory.h> would be much better: it does not exist
> on many platforms.

In the POSIX world, reality is quite different from the rest of the
world.  Here, <memory.h> is almost everywhere.

> If we are going to introduce a new separation, let
> us make it a good one.

For the reasons above, even if <memory.h> didn't exist, I'd say the
3-header solution it's not ideal.

> Christopher


Have a lovely day!
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

[Sam James]

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

Alejandro Colomar <alx@kernel.org> writes:

> Hi Sam,
>
>> Date: 2026-08-01 15:38:42+0100
>> From: Sam James <sam@gentoo.org>
>>
> [...]
>> >
>> > I'd say I have a history of making changes based on thorough revision of
>> > history and technical merits, even when that research is contrary to
>> > decades (or half-centuries) of common practice, and possibly to
>> > current or withdrawn standards.
>> 
>> The primary issue I have is that I don't often see you change your mind
>
> I do quite frequently, actually.  Most recently, this week:
>
> <https://lore.kernel.org/linux-man/CAMdZqKEEncWS64BUL1qa0SfcNUaNA9XRBPWTpHPB==N3VV_Nzg@mail.gmail.com/>
> <https://lore.kernel.org/linux-man/amupqzN_X57Du4AJ@devuan/>

OK, I don't frequently see you change your mind on any of these big
contentious threads we have every so often.

>
> 	> Date: Thu, 30 Jul 2026 21:51:16 +0200
> 	> From: Alejandro Colomar <alx@kernel.org>
> 	>
> 	> > Date: Thu, 30 Jul 2026 10:58:26 -0700
> 	> > From: Mark Harris <mark.hsj@gmail.com>
> 	> >
> 	> > It seems like you've already made up your mind that memccpy()
> 	> > is bad and are now just looking to justify that decision.
> 	>
> 	> Not necessarily.  I can be convinced with good arguments.  :-)
> 	>
> 	...
> 	> Agreed; there are use cases where memccpy(3) is preferrable.
> 	> You've convinced me.  :)
>
> There are many other cases about cases where I had a strong opinion, and
> people that are currently in CC have changed my mind.
>
> Even you've changed my mind a few times, even if you don't remember or
> didn't realize.

OK.

>
>> or acknowledge that being the man-pages maintainer is a privileged
>> position,
>
> It's certainly a privileged position.  Just like maintainer of GCC, or
> of Clang, or any other core project of most systems.  I acknowledge
> this, and I believe I've acknowledged this before, implicitly and
> explicitly.
>
>> or separate your desires from the maintainership role.
>
> My only desires are making it easy to allow programmers to write good
> programs.  I believe that's my main responsibility as maintainer of this
> project, and in general, the task of any good documentation.

I think the previous man-pages maintainer behaved differently and people
have come to expect that style of management over the years.

>
>> When I'm acting in a maintainer role, I often take changes I don't
>> particularly agree with if they're technically sound and there's broad
>> consensus for them. I think many do.
>
> I also do often (and you probably don't notice, because you're not part
> of this project, and are not here to observe every change).  But
> sometimes, I must make decisions that some people --no matter how
> important-- may disagree with.  I might be wrong, and I'll certainly
> re-think about them after-the-fact, but this is one of them.
>

I'm saying that you seem to be in the position of making such changes
more than many.

>> > In this case, and I don't mean this specific patch set, but the years-
>> > long revision of string documentation that I've been carrying out, we
>> > have a conflict between the design and correct use of string and memory
>> > functions, and their common use today.
>> >
>> 
>> Yes, I don't dispute that the terminology is poor.
>
> It's not only a matter of terminology.  And in fact, I thing the
> terminology could be acceptable (not ideal, though).
>

OK, I'm saying I don't disagree that strings vs memory is a mess in C.

>> > The functions that are most subject to this conflict are strncpy(3),
>> > strncat(3), and memccpy(3).  But the rest of strn*() are also somewhat
>> > affected, and the rest of mem*() minorly affected.
>> >
>> > They were originally designed for a specific use case for which they
>> > were great.  This knowledge has been lost in time, and I've been working
>> > to recover that knowledge.
>> >
>> > Precisely because of standards and other documentation that isn't
>> > written with the level of care that I have, we have decades of misuses
>> > of strncpy(3) and strncat(3).
>> >
>> > Moreover, it's in other places that you should be complaining about.
>> 
>> I do complain about those, and we finally got some consensus on the GCC
>> side on not warning about a bunch of them by default, even.
>
> What do you mean?  And why have I not been CCed in such discussions,
> after being the original reporter of the problems?  That kind of issue
> management is certainly worse than what we're discussing here.
>

???

First, it wouldn't make sense to CC every reporter of such a bug
involving middle-end warnings on such a thread.

Second, there have been several such discussions on the ML and at the
GNU Cauldron, the most recent one I'm referring to being
https://inbox.sourceware.org/gcc/CAH6eHdRfEVsGjbJ__kU5AR9BfVdLQZ_iGGDZa=yQnT4fgG2P6w@mail.gmail.com/.

There have been (many) others regarding both the FP nature of the
warnings and also growing consensus on IRC and the MLs when these issues
come up that some of them are too opinionated in addition to being
heuristics-based. Some of them are based on style that shouldn't really
be in the warnings (or at least not on by default if so), and some of it
is inherently prone to false-positives, some both.

> I believe that even though I may disagree with others, it's good to hear
> their opinions, no matter how convinced I am that they're wrong, and no
> matter how much they'll blame me for taking bad decisions.  Feedback is
> (almost) always good, even when it's negative.
>
> What exact changes have consensus in GCC?  How can there be consensus if
> you haven't CCed the relevant people (including me)?
>

See above.

> In any case, I guess it's good if GCC will improve.
>
>> > GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
>> > which we could very well call opinionated, and I haven't seen anyone
>> > reporting them as bogus before I did.  Those diagnostics have not been
>> > considered opinionated, just because they follow mainstream (bogus)
>> > usage of these functions, but they are indeed forcing an opinion of how
>> > these functions should be used over other uses that may be more uncommon
>> > but which are actually the original and correct uses of these functions.
>> > <https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
>> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
>> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>
>> >
>> > It's curious that you called the GCC diagnostic "heuristics" instead of
>> > "opinionated".  There's nothing about heuristics there.  It's just an
>> > enforcement of an (incorrect) opinion about how these functions should
>> > be used.
>> 
>> The warnings are both opinionated
>
> Thanks!
>
>> and heuristics-based. I'm not sure how
>> you could read the comment you linked to as somehow an endorsement of
>> the status quo,
>
> I don't read it as an endorsement of the status-quo.  Just a diminishing
> of the fact that GCC maintainers, just like every other project, have
> opinions --sometimes, like here, wrong opinions--, and they affect
> other programmers that try to write good code.
>
>> I've been quite vocal about changing it elsewhere too?
>
> I'm not aware of anything that has not me in CC; sorry.

I wasn't in CC yet I came across this thread. Should you have CCed me?

(No, I don't believe you should have; this is what mailing lists are
for.)

>
>> > And since C23, we're seeing that the same story is repeating with
>> > memccpy(3), which was once a niche function that was great for
>> > implementing fgets(3), and now is misused by everyone and their dog for
>> > copying strings with truncation.
>> >
>> > I have spent probably more time than anyone in the last 5 years
>> > researching about string handling, and have proven the correctness of my
>> > research in the shadow-utils project, where most of my work has been in
>> > revising string and memory handling code.  I've fixed uncountable subtle
>> > bugs in such code, and have made the resulting code actually readable.
>> > And the number of accidental regressions is minimal (IIRC, one or two
>> > regressions related to string and memory handling, in all that time, and
>> > not too dangerous).
>> >
>> > Thus, I think it is my responsibility, as maintainer of the
>> > documentation project most read by C programmers, to let our audience
>> > learn what I've learnt in these years, and allow them to write safe
>> > string- and memory-handling code.
>> >
>> > It is thanks to this years-long research that I've been able to gather
>> > important knowledge from people like Mark Harris, Doug McIlroy, Branden,
>> > and many others, who hold knowledge that few other programmers possess,
>> > and spread it to the world.
>> >
>> > I'd consider it a negligence to do the easy thing and follow what
>> > standards say, or what most programmers do, because that's what has led
>> > us to the well-known mistakes that C programmers make.
>> >
>> > FWIW, regarding the possible conflict of interest that was mentioned
>> > yesterday, I'll say that I don't get paid for my contributions to ISO C
>> > as a member of WG14.  There's no benefit to me other than public
>> > recognition.  I'll also disclose the exact quantity that I've been paid
>> > for maintaining the Linux man-pages project:
> [...]
>> In fact, I have never believed you were influenced by
>> money,
>
> Thanks!
>
>> just that you let your personal opinions unduly influence your
>> decisions in modifying man-pages,
>
> I've done a lot of research and hearing experts to reach this
> decision(s).  I believe it's not just an opinion, but a technical
> decision even if a controversial one.
>
> [reordered]
>> You can have a conflict of interest in responsibliity without money
>> being involved.
>
> I'll continue to think about this and other concerns, and may change my
> mind later.  At this moment, I believe I'm taking a technical decision
> after hearing enough experts and researching the topic more than anyone
> for several years.
>
>> even when consensus seems against it.
>
> I wouldn't say consensus against; just a vocal number of people that
> disagree.  I wouldn't say there's consensus in favour, of course, but
> when there's no consensus, I have to take the last decision.  Most of
> the time, that last decision means not doing anything, but in this case,
> it's different.

What would real consensus against look like?

>
>
> Cheers,
> Alex

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

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Sam,

> Date: 2026-08-01 17:10:30+0100
> From: Sam James <sam@gentoo.org>
>
[...]
> 
> I think the previous man-pages maintainer behaved differently and people
> have come to expect that style of management over the years.

I know Michael, and still have regular contact with him.  We have
a sligthly different management style in some topics, indeed.  Not
saying any of them is better or worse, though.

[...]
> >> I do complain about those, and we finally got some consensus on the GCC
> >> side on not warning about a bunch of them by default, even.
> >
> > What do you mean?  And why have I not been CCed in such discussions,
> > after being the original reporter of the problems?  That kind of issue
> > management is certainly worse than what we're discussing here.
> >
> 
> ???
> 
> First, it wouldn't make sense to CC every reporter of such a bug
> involving middle-end warnings on such a thread.

I'm not a random one-time reporter.

> Second, there have been several such discussions on the ML and at the
> GNU Cauldron, the most recent one I'm referring to being
> https://inbox.sourceware.org/gcc/CAH6eHdRfEVsGjbJ__kU5AR9BfVdLQZ_iGGDZa=yQnT4fgG2P6w@mail.gmail.com/.

I'm not subscribed to gcc's mailing list.

> There have been (many) others regarding both the FP nature of the
> warnings and also growing consensus on IRC and the MLs when these issues
> come up that some of them are too opinionated in addition to being
> heuristics-based. Some of them are based on style that shouldn't really
> be in the warnings (or at least not on by default if so), and some of it
> is inherently prone to false-positives, some both.

Attributing those diagnostics to style is wrong.  They are based on an
incorrect understanding of these functions.  Style is whether to add
spaces after a function identifier or not.

It's not a matter of false-positives either.  The entire diagnostic is
*always* unconditionally wrong.

> > I believe that even though I may disagree with others, it's good to hear
> > their opinions, no matter how convinced I am that they're wrong, and no
> > matter how much they'll blame me for taking bad decisions.  Feedback is
> > (almost) always good, even when it's negative.
> >
> > What exact changes have consensus in GCC?  How can there be consensus if
> > you haven't CCed the relevant people (including me)?
> >
> 
> See above.
> 
> > In any case, I guess it's good if GCC will improve.
> >
> >> > GCC has a bogus set of diagnostics about strncpy(3) and strncat(3),
> >> > which we could very well call opinionated, and I haven't seen anyone
> >> > reporting them as bogus before I did.  Those diagnostics have not been
> >> > considered opinionated, just because they follow mainstream (bogus)
> >> > usage of these functions, but they are indeed forcing an opinion of how
> >> > these functions should be used over other uses that may be more uncommon
> >> > but which are actually the original and correct uses of these functions.
> >> > <https://inbox.sourceware.org/gcc/30a77019-ded0-fe3b-d0db-6c77842674db@gmail.com/>
> >> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123024>
> >> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122963>
> >> >
> >> > It's curious that you called the GCC diagnostic "heuristics" instead of
> >> > "opinionated".  There's nothing about heuristics there.  It's just an
> >> > enforcement of an (incorrect) opinion about how these functions should
> >> > be used.
> >> 
> >> The warnings are both opinionated
> >
> > Thanks!
> >
> >> and heuristics-based. I'm not sure how
> >> you could read the comment you linked to as somehow an endorsement of
> >> the status quo,
> >
> > I don't read it as an endorsement of the status-quo.  Just a diminishing
> > of the fact that GCC maintainers, just like every other project, have
> > opinions --sometimes, like here, wrong opinions--, and they affect
> > other programmers that try to write good code.
> >
> >> I've been quite vocal about changing it elsewhere too?
> >
> > I'm not aware of anything that has not me in CC; sorry.
> 
> I wasn't in CC yet I came across this thread. Should you have CCed me?

I did indeed CC bug-gnulib@ and libc-alpha@.  I could have kept the
discussion in linux-man@, if I wasn't interested in hearing from you and
other people who are likely to be interested in being aware and sharing
their opinions.

And that's also why I CCed Joseph and other people explicitly, as they
have expressed opinions about this topic in previous discussions.

I think this is a good guideline:

       Please CC any relevant developers and mailing lists that may know
       about or be interested in the discussion.  If your email
       discusses a feature or change, and you know which developers
       added the feature or made the change that your email discusses,
       please CC them on the email; with luck they may review and
       comment on it.  If you don't know who the developers are, you may
       be able to discover that information from mailing list archives
       or from git(1) logs or logs in other version control systems.
       Obviously, if you are the developer of the feature being
       discussed in a man-pages email, please identify yourself as such.
       Relevant mailing lists may include:

> (No, I don't believe you should have; this is what mailing lists are
> for.)

I disagree.  But that might be a difference in project conventions.  The
guidelines we use here, which come from Michael, and are similar to the
kernel's ones, are to CC people explicitly when they might be
interested.  I'm aware that GCC has a different tradition in this
regard, though.

[...]
> >> You can have a conflict of interest in responsibliity without money
> >> being involved.
> >
> > I'll continue to think about this and other concerns, and may change my
> > mind later.  At this moment, I believe I'm taking a technical decision
> > after hearing enough experts and researching the topic more than anyone
> > for several years.
> >
> >> even when consensus seems against it.
> >
> > I wouldn't say consensus against; just a vocal number of people that
> > disagree.  I wouldn't say there's consensus in favour, of course, but
> > when there's no consensus, I have to take the last decision.  Most of
> > the time, that last decision means not doing anything, but in this case,
> > it's different.
> 
> What would real consensus against look like?

Well, Keith Bostic wouldn't have suggested that I do this change, and
Branden wouldn't be defending that it might make sense to make this
change.

A vocal majority is not consensus.  Consensus would be if there were no
significantly different or strongly opposed opinions to those of the
majority.  Even my strong and sustained opposition against your opinion
already means there's no consensus against.


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

[G. Branden Robinson]

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

Hi Doug,

At 2026-08-01T08:39:08-0400, Douglas McIlroy wrote:
> Branden wrote
> > 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.
> 
> Yes, this is a property of the language, not a peculiar deficiency of
> the <string.h> functions.

I mostly agree.  I think it's possible that C's string interfaces
managed to innovate some deficiencies of their own on top of those
proferred by the underlying the language definition.  8-O

> As I see it, patching up perceived deficiencies of the functions adds
> complexity to the language definition and to the task of code-reading,

That's true.  But it is also true that without clear guidance from the
standard's specification of the library, and with the flagship text on
the language having gone unrevised since 1988, those perceived
deficiencies cause ad hoc innovations to sprout like mushrooms after a
thunderstorm.  Some of those innovations, like OpenBSD's strlcat and
strlcpy (1998), claw their way into acceptance.  Others don't, and
remain bespoke features of a particular code project--often with little
commentary or accompanying documentation to illuminate them.

The result?  Reading _any_ code that involves string/`char` sequence/
memory buffer handling has a substantial complexity tax stuck onto it.

Culturally, it used to be that any inadequacies of the C language or its
standard library were hand-waved away because a coder of sufficient
ability could bull through any challenge with cleverness.  Our community
has been purged of that preening vanity ten thousand CVEs at a time.

I think one of the reasons Alex is getting pushback is that everybody
knows this is a horrible can of worms--Joseph referred to "relitigation"
--and that in turn is because seasoned C practitioners have a shared
dread that instead of a brilliant solution existing somewhere in library
design space, we face only struggles over who the taxing authorities
shall be.  And everybody hates the tax man.

> with little real benefit.

If there is no Pareto improvement available in any dimension, but just
reshuffling of code-reading tax authorities, then you're right.

I can, at best, hope the situation is not that bad.

If it is, what is to be done?

Regards,
Branden

[-- 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: 1799 bytes --]

Hi Sam & Alex,

Just a quick note on conflicts on interest since I'm the one who dragged
that label into the conversation--though the concept was implicitly
present already.

At 2026-08-01T15:38:42+0100, Sam James wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> > FWIW, regarding the possible conflict of interest that was mentioned
> > yesterday, I'll say that I don't get paid for my contributions to
> > ISO C as a member of WG14.  There's no benefit to me other than
> > public recognition.  I'll also disclose the exact quantity that I've
> > been paid for maintaining the Linux man-pages project:
> 
> You can have a conflict of interest in responsibliity without money
> being involved. In fact, I have never believed you were influenced by
> money,

Sam makes a good point, and Alex, I think you overlooked one.

Disclosure of the quantity of your compensation as Linux man-pages
maintainer is of less importance than _who_ sponsored your work.

When we're speaking of currency, yes, quantity eventually has a quality
all its own.  But knowing who's been signing the checks is almost always
the more valuable information because it tells us who is in a position
to expect favorable treatment.  Sometimes that's because the parties
negotiate a quid pro quo, but more often sponsors can count on
"self-regulation" by their beneficiaries.  Money men understand that
people's minds and uncritical loyalties can often be bought cheaply.

Free your mind and something else will follow, I think someone said.

Here's a backgrounder that's less antiseptic than a corporate ethics
slide deck training module on conflicts of interest.

https://www.propublica.org/article/clarence-thomas-money-complaints-sparked-resignation-fears-scotus

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

[Alejandro Colomar]

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

Hi Branden, Doug,

> Date: 2026-08-01 14:54:35-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Doug,
> 
> At 2026-08-01T08:39:08-0400, Douglas McIlroy wrote:
> > Branden wrote
> > > 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.
> > 
> > Yes, this is a property of the language, not a peculiar deficiency of
> > the <string.h> functions.

Actually, I'm going to disagree on the first principle: the language is
not flawed, and <string.h> functions aren't particularly bad either.

The fact that they can be used safely after you understand the tools
means that the tools are good.  It's the teaching that has been bad.

Just like with every sharp tool, you need to first understand the tool.

After 5 years of researching about <string.h> functions, I've proved
with example that one can rewrite vast amounts of string code without
regressions every two lines of code.  This can only mean that <string.h>
is not inherently dangerous, since I'm not especially free from the
human-mistake factor (actually, I feel I'm more prone to them than the
average programmer).

<string.h> lacks a few functions and macros that make life much simpler,
such as Linux's strscpy(9), gnulib's streq(3), and a few others.

That lack, I attribute it to the fact that programmers have been burnt
so many times on bad design that they have grown an aversion to adding
them.  The fiasco of Annex K has probably helped.

> I mostly agree.  I think it's possible that C's string interfaces
> managed to innovate some deficiencies of their own on top of those
> proferred by the underlying the language definition.  8-O
> 
> > As I see it, patching up perceived deficiencies of the functions adds
> > complexity to the language definition and to the task of code-reading,

I'm currently just proposing a documentation change (there's another
proposal I'm working on in parallel, which actually affects the
functions, but that's not what we're discussing now).  The functions are
virtually moved to a different header file, but nothing else changes.

That header file division will help with the teaching problem, which is
the problem that has affected <string.h> so badly for so long.

> That's true.  But it is also true that without clear guidance from the
> standard's specification of the library, and with the flagship text on
> the language having gone unrevised since 1988, those perceived
> deficiencies cause ad hoc innovations to sprout like mushrooms after a
> thunderstorm.  Some of those innovations, like OpenBSD's strlcat and
> strlcpy (1998), claw their way into acceptance.

And interestingly, OpenBSD's strlcpy/cat(3) suffer from DoS, which
Linux's strscpy(9) is free of.

> Others don't, and
> remain bespoke features of a particular code project--often with little
> commentary or accompanying documentation to illuminate them.

Indeed.

> The result?  Reading _any_ code that involves string/`char` sequence/
> memory buffer handling has a substantial complexity tax stuck onto it.

And indeed.

> Culturally, it used to be that any inadequacies of the C language or its
> standard library were hand-waved away because a coder of sufficient
> ability could bull through any challenge with cleverness.  Our community
> has been purged of that preening vanity ten thousand CVEs at a time.

And indeed.

> I think one of the reasons Alex is getting pushback is that everybody
> knows this is a horrible can of worms

I'd say they think they know.  I believe it's not a can of worms, if you
are strict about keeping it simple.

> --Joseph referred to "relitigation"

And because the C Committee has the bad habit of considering past
decisions of the committee as godspell, no matter how bad they prove to
be.  I've been repeatedly accused of relitigating realloc(p,0),
<string.h>, and many more bad decisions of ISO C.

One good news is that Microsoft is currently testing my proposed changes
to fix realloc(p,0), and when their testing is done, all the FUD that
we've been hearing that it can't be changed now because "it would break
the world" will just vanish.

> --and that in turn is because seasoned C practitioners have a shared
> dread that instead of a brilliant solution existing somewhere in library
> design space, we face only struggles over who the taxing authorities
> shall be.  And everybody hates the tax man.
> 
> > with little real benefit.
> 
> If there is no Pareto improvement available in any dimension, but just
> reshuffling of code-reading tax authorities, then you're right.
> 
> I can, at best, hope the situation is not that bad.

I am certain that the solution exists.

> If it is, what is to be done?


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

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-08-01 15:18:49-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Sam & Alex,
> 
> Just a quick note on conflicts on interest since I'm the one who dragged
> that label into the conversation--though the concept was implicitly
> present already.
> 
> At 2026-08-01T15:38:42+0100, Sam James wrote:
> > Alejandro Colomar <alx@kernel.org> writes:
> > > FWIW, regarding the possible conflict of interest that was mentioned
> > > yesterday, I'll say that I don't get paid for my contributions to
> > > ISO C as a member of WG14.  There's no benefit to me other than
> > > public recognition.  I'll also disclose the exact quantity that I've
> > > been paid for maintaining the Linux man-pages project:
> > 
> > You can have a conflict of interest in responsibliity without money
> > being involved. In fact, I have never believed you were influenced by
> > money,
> 
> Sam makes a good point, and Alex, I think you overlooked one.
> 
> Disclosure of the quantity of your compensation as Linux man-pages
> maintainer is of less importance than _who_ sponsored your work.

That's public, and has been since the begining.  It's published in the
git repository:

	$ cat SPONSORS 
	Google               <https://opensource.google/>
	Hudson River Trading <https://www.hudsonrivertrading.com/>
	Meta                 <https://www.meta.com/>

Here's the history of that file:

	$ git log --pretty=reference -p -- SPONSORS 
	6d9ae347cfac (SPONSORS: Two sponsors didn't renew this year, 2025-10-29)

	diff --git a/SPONSORS b/SPONSORS
	index 440fcca8b9ed..4b2f2e9011b8 100644
	--- a/SPONSORS
	+++ b/SPONSORS
	@@ -1,5 +1,3 @@
	-Adfinis              <https://adfinis.com/>
	 Google               <https://opensource.google/>
	 Hudson River Trading <https://www.hudsonrivertrading.com/>
	 Meta                 <https://www.meta.com/>
	-Red Hat              <https://www.redhat.com/>
	7ea35690e060 (SPONSORS: Publish the sponsors of this project, 2025-01-15)

	diff --git a/SPONSORS b/SPONSORS
	new file mode 100644
	index 000000000000..440fcca8b9ed
	--- /dev/null
	+++ b/SPONSORS
	@@ -0,0 +1,5 @@
	+Adfinis              <https://adfinis.com/>
	+Google               <https://opensource.google/>
	+Hudson River Trading <https://www.hudsonrivertrading.com/>
	+Meta                 <https://www.meta.com/>
	+Red Hat              <https://www.redhat.com/>


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

[Alejandro Colomar]

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

> Date: 2026-08-01 22:42:15+0200
> From: Alejandro Colomar <alx@kernel.org>
>
[...]
> 	$ git log --pretty=reference -p -- SPONSORS 
> 	6d9ae347cfac (SPONSORS: Two sponsors didn't renew this year, 2025-10-29)
> 
> 	diff --git a/SPONSORS b/SPONSORS
> 	index 440fcca8b9ed..4b2f2e9011b8 100644
> 	--- a/SPONSORS
> 	+++ b/SPONSORS
> 	@@ -1,5 +1,3 @@
> 	-Adfinis              <https://adfinis.com/>
> 	 Google               <https://opensource.google/>
> 	 Hudson River Trading <https://www.hudsonrivertrading.com/>
> 	 Meta                 <https://www.meta.com/>
> 	-Red Hat              <https://www.redhat.com/>

FWIW, the reason for those two that dropped, IMO, is that Adfinis is
a small company that couldn't afford it, and Red Hat probably did to
have more cash to burn in the AI oven.


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

[G. Branden Robinson]

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

Hi Alex,

At 2026-08-01T22:42:09+0200, Alejandro Colomar wrote:
> That's public, and has been since the begining.  It's published in the
> git repository:

I knew it was there somewhere.  (I see now--prominently, even!)

> 	$ cat SPONSORS
> 	Google               <https://opensource.google/>
> 	Hudson River Trading <https://www.hudsonrivertrading.com/>
> 	Meta                 <https://www.meta.com/>

I don't think many occasions call for you to quote the file contents.
In your position I would simply have the URL to this file handy for any
occasion where someone takes a run at my transparency.

In fact I think your approach to disclosure is near-optimal.  In my view
it is strongly superior to slathering acknowledgements of your sponsors
on all of your emails in your capacity as Linux man-pages maintainer,
which would degrade software engineering into something like NASCAR.

(There I go, alienating yet another fan community...)

Regards,
Branden

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

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-08-01 15:52:26-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Alex,
> 
> At 2026-08-01T22:42:09+0200, Alejandro Colomar wrote:
> > That's public, and has been since the begining.  It's published in the
> > git repository:
> 
> I knew it was there somewhere.  (I see now--prominently, even!)

:)

> 
> > 	$ cat SPONSORS
> > 	Google               <https://opensource.google/>
> > 	Hudson River Trading <https://www.hudsonrivertrading.com/>
> > 	Meta                 <https://www.meta.com/>
> 
> I don't think many occasions call for you to quote the file contents.

In every release, I do it.  For example, see the last one:

<https://lore.kernel.org/linux-man/aekjQuAEaq1ILKAa@devuan/>

	> From: Alejandro Colomar <alx@kernel.org>
	> To: linux-man@vger.kernel.org
	> Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org
	> Subject: man-pages-6.18 released
	> Date: Wed, 22 Apr 2026 22:04:52 +0200	[thread overview]
	> Message-ID: <aekjQuAEaq1ILKAa@devuan> (raw)
	> 
	> Gidday!
	> 
	> I'm proud to announce:
	> 
	> 	man-pages-6.18 - manual pages for GNU+Linux
	> 
	...
	> 
	> Thanks to all the contributors to this release (in BCC)!
	> And thanks to our sponsors!
	> 
	> 	$ sort --random-sort <SPONSORS;
	> 	Meta                 <https://www.meta.com/>
	> 	Hudson River Trading <https://www.hudsonrivertrading.com/>
	> 	Google               <https://opensource.google/>

Properly random-sorted, to avoid any preferences.  In the actual file,
they're sorted alphabetically.  I haven't even asked how much money each
of them pays to me, because I don't want to know.  I only get the total
amount through the Linux Foundation.  (But FWIW, I guess the three pay
the same.)

> In your position I would simply have the URL to this file handy for any
> occasion where someone takes a run at my transparency.

Yup.

> In fact I think your approach to disclosure is near-optimal.

I've been thinking that I should disclose the total amount in the commit
messages that update the file.

>  In my view
> it is strongly superior to slathering acknowledgements of your sponsors
> on all of your emails in your capacity as Linux man-pages maintainer,
> which would degrade software engineering into something like NASCAR.

I do in the releases, but since they only happen a few times a year,
I guess it's okay.

> (There I go, alienating yet another fan community...)
> 
> Regards,
> Branden


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

[G. Branden Robinson]

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

Hi Alex,

At 2026-08-01T19:09:36+0200, Alejandro Colomar wrote:
> Well, Keith Bostic wouldn't have suggested that I do this change, and
> Branden wouldn't be defending that it might make sense to make this
> change.

I'm flattered to be mentioned in the same breath as Keith Bostic!

> A vocal majority is not consensus.  Consensus would be if there were
> no significantly different or strongly opposed opinions to those of
> the majority.  Even my strong and sustained opposition against your
> opinion already means there's no consensus against.

"Consensus" is a word that gets abused a lot, because it has multiple
definitions.  To some people it means "unanimity".  To others, it means
a majority vote with potentially many abstentions but no (or
proportionally very few) negative votes.  From reading WG14 minutes, I'm
vaguely aware that it has a rubric for reading the straw polls they take
when voting on N-papers and related motions.[1]  I invite a member to
cite a resource laying out their actual procedures.

I don't think I'm voicing a controversial view when I venture that
Michael Kerrisk administered the Linux man-pages with a more settled
view of the APIs it documents.  By that, I mean that he tended to update
its content with a retrospective view of matters that were no longer in
contention.  If some controversy brewed, he tended to omit it from
"coverage" in the documentary corpus until the contention resolved.

Your approach is a little different: you're more ready to give the
reader a view of live controversies and unsettled matters troubling the
C community where these intersect with the topics man-pages(7) covers.

Neither approach is better.  They're just different.  I think Sam is
right that people had many years to get used to Michael's approach.
From there it's a short--but logically unsound--step to associate
"familiar" with "better".

But, if you're going to document unresolved controversies, how do you
avoid putting a thumb on the scale?

One way is to solicit review of that coverage for even-handedness--I
do not say "neutrality".  List pros and cons of competing interfaces or
code idioms.  If you do that job correctly, _reasonable_ partisans of
the various contesting positions will find no cause to criticize.
(There will sometimes be fanboys who object to the "opposition" getting
any coverage at all.)

Further, with such lists you do a service to the engineer who must
select a means of solving the problem confronting them.  The engineer
often knows that problem better than anyone else does.

Next comes a trickier bit: what if you yourself get involved, even while
"wearing a different hat", in one of these live controversies?

Your first line of defense is your own ethical conscience.

Another, as I suggested earlier, is to solicit one or more volunteers to
serve as "deputy maintainers".  Prepare a list of man pages or sections
thereof upon which you are "conflicted out", and ask the deputies to
field all Linux man-pages business regarding those pages/sections while
you have business regarding those interfaces before a vendor libc and/or
the WG14 committee.  It will likely be obvious to you what vehicle can
communicate these areas of deputy maintenance--a man page!

I intuit that Michael had a hard time finding anyone to take the mantle
of Linux man-pages maintainership.  It's a huge job and demanded someone
of your unusual resources and energy.  By opening deputy positions that
are limited both in scope and in time, nobody need worry that they'll be
expected to eat the whole elephant.  If you find such volunteers, then
you'll also be spreading expertise and socializing personal investment
in the success of this project.  That's good management!

Finally, to return to the question of consensus: a potential point of
development in Linux man-pages project governance is to _document how
you measure consensus_.

We'd be unwise to determine consensus by measuring who writes the most
words (hi, folks), or with the angriest tone, or who has the most
impressive job title at the biggest company, or who can shut down a
discussion most coldly or derail it most effectively.

So tell the members of this community how _you_ measure it.  Put the
burden on the critical and the concerned to find flaws in your method.

Regards,
Branden

[1]  I'm not sure WG14 uses the term "motions", and I haven't seen much
     evidence that they use Robert's Rules of Order, with which
     Commonwealth people are likely not familiar, let alone
     non-Anglophones.

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

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-08-01 16:34:21-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Alex,
> 
> At 2026-08-01T19:09:36+0200, Alejandro Colomar wrote:
> > Well, Keith Bostic wouldn't have suggested that I do this change, and
> > Branden wouldn't be defending that it might make sense to make this
> > change.
> 
> I'm flattered to be mentioned in the same breath as Keith Bostic!

:)

> > A vocal majority is not consensus.  Consensus would be if there were
> > no significantly different or strongly opposed opinions to those of
> > the majority.  Even my strong and sustained opposition against your
> > opinion already means there's no consensus against.
> 
> "Consensus" is a word that gets abused a lot, because it has multiple
> definitions.  To some people it means "unanimity".  To others, it means
> a majority vote with potentially many abstentions but no (or
> proportionally very few) negative votes.

Indeed.

> From reading WG14 minutes, I'm
> vaguely aware that it has a rubric for reading the straw polls they take
> when voting on N-papers and related motions.[1]  I invite a member to
> cite a resource laying out their actual procedures.

WG14, like WG21, has a problem.  Consensus, these days, is taken as
roughly a majority of votes.

With very few exceptions, here's the rule that guides consensus in straw
polls during committee meetings:

		// Consensus requires both
		//	y/(y+n)   >= 2/3
		//	n/(y+n+a) <= 1/4

Strong opposition is dismissed as long as the numbers are okay.  We even
have a small program that performs that calculation and which we
consult.

As a consequence, this is what happens (very interesting read):
<https://isocpp.org/files/papers/P4238R0.pdf>.

A large number of NBs (national bodies), including mine, are going to
vote against C++26, and as a consequence, it may be returned to WG21 for
evaluation.  This means we won't have C++26 if this happens.

> I don't think I'm voicing a controversial view when I venture that
> Michael Kerrisk administered the Linux man-pages with a more settled
> view of the APIs it documents.  By that, I mean that he tended to update
> its content with a retrospective view of matters that were no longer in
> contention.  If some controversy brewed, he tended to omit it from
> "coverage" in the documentary corpus until the contention resolved.

Yup.

> Your approach is a little different: you're more ready to give the
> reader a view of live controversies and unsettled matters troubling the
> C community where these intersect with the topics man-pages(7) covers.

Yup.

> Neither approach is better.  They're just different.

Yup.

> I think Sam is
> right that people had many years to get used to Michael's approach.
> From there it's a short--but logically unsound--step to associate
> "familiar" with "better".

Yup.

> But, if you're going to document unresolved controversies, how do you
> avoid putting a thumb on the scale?

Doing a lot of research.  Whatever I don't research myself, I still act
like Michael, and tend to not step into.  But string and memory handling
is something that has taken most of my time in the last 5 years or so.

> One way is to solicit review of that coverage for even-handedness--I
> do not say "neutrality".  List pros and cons of competing interfaces or
> code idioms.

I do indeed get that.  Mark gave me feedback about memccpy(3) recently,
which I've incorporated to my research.  That was the last issue I had
with <string.h>, because memccpy(3) is something I've never seen in real
correct use.  It seems Illumos is one of the places where they store
that old knowledge.  It's good that those projects still exist and can
be used to learn about our history.

Sam was concerned about not docuementing what standards say; and indeed,
I'll make sure to document that (in STANDARDS, where it belongs; which
I had already done, BTW).  Other than that, he was worried that I might
be encoding an opinion, but I believe this is a technical judgement
based on research, and not an opinion.  So, dismissed.

Joseph was concerned that this documentation would conflict with many
documents saying that <memory.h> is deprecated.  Luckily, I've never
seen such a document, so we can assume they don't exist (unless people
show evidence).  I'll dismiss his negative vote, since his technical
reasons are incorrect.  Also, <memory.h> is undoubtedly more portable 
than a new <stdmem.h>.

It's also a bit Ironic that Joseph started with a strongly opinionated
proposal: deprecating <memory.h> in glibc (breaking 8.9k uses in
Debian).

Collin didn't comment, although by his support to Joseph's suggestion
of deprecating <memory.h>, I guess he's against.  Since he didn't
provide any new reasons, I guess it's more of Joseph's.  Already
dismissed, then.

Nevin has an undeclared conflict of interest:  He is the author of a
proposal for WG14 to remove strncpy(3).
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3935.htm>
Also, he didn't really give any technical reasons; he just voted no.
A vote without reasons is still heard, but easily dismissed.

Keith suggested doing this, by which I assume he's in favour.  He's
certainly an expert in the topic, and I'd value his support.

I value Doug's opinion too, although he didn't show much technical
reasons this time.  He was mostly concerned about changing string
functions, but didn't clarify whether he was concerned about restoring
<memory.h>.  Thus, I'd say I won't count that.

You seem to support the fact that something should be done, except that
you may not entirely agree with the approach.  You've been a bit
misguided by Joseph's concerns about <memory.h>, so I'll dismiss that
part of your feedback as being just Joseph's --which I've already
dismissed on technical grounds--.

Chris is concerned about my arbitrary separation, but I think his
separation is also somewhat arbitrary.  I'll trust my instinct here.
We're always in time to revise this.  In any case, this arbitrary
distinction is better than the status quo.

Thus, with support from Keith, and no sustained opposition based on
technical ground (Joseph didn't contest my response that absolutely no
mainstream documents talk about <memory.h> being deprecated, and himself
said that it's only *implicitly* deprecated), I should commit.

>  If you do that job correctly, _reasonable_ partisans of
> the various contesting positions will find no cause to criticize.
> (There will sometimes be fanboys who object to the "opposition" getting
> any coverage at all.)
> 
> Further, with such lists you do a service to the engineer who must
> select a means of solving the problem confronting them.  The engineer
> often knows that problem better than anyone else does.
> 
> Next comes a trickier bit: what if you yourself get involved, even while
> "wearing a different hat", in one of these live controversies?
> 
> Your first line of defense is your own ethical conscience.
> 
> Another, as I suggested earlier, is to solicit one or more volunteers to
> serve as "deputy maintainers".  Prepare a list of man pages or sections
> thereof upon which you are "conflicted out", and ask the deputies to
> field all Linux man-pages business regarding those pages/sections while
> you have business regarding those interfaces before a vendor libc and/or
> the WG14 committee.  It will likely be obvious to you what vehicle can
> communicate these areas of deputy maintenance--a man page!
> 
> I intuit that Michael had a hard time finding anyone to take the mantle
> of Linux man-pages maintainership.  It's a huge job and demanded someone
> of your unusual resources and energy.  By opening deputy positions that
> are limited both in scope and in time, nobody need worry that they'll be
> expected to eat the whole elephant.  If you find such volunteers, then
> you'll also be spreading expertise and socializing personal investment
> in the success of this project.  That's good management!

I have a mental list of people to whom I consult when I don't think
I should make the decision alone.  The list isn't fixed, and varies
wildly depending on the topics, but you can get an idea when I CC people
in discussions.  You've been yourself quite some times.  :)

> Finally, to return to the question of consensus: a potential point of
> development in Linux man-pages project governance is to _document how
> you measure consensus_.

Nope.  I'll quote <https://isocpp.org/files/papers/P4238R0.pdf>:

	2. How Consensus Is Supposed to Work
	WG21 decides by consensus, not by vote.  The chair, a
	subject-matter expert, weighs the arguments of every side.
	Where they can be reconciled, the chair reconciles them.  Where
	they cannot be reconciled, the chair decides, and may decide
	against the numerical majority.  This is deliberate: WG21's own
	guidance states that "the chair's determination of consensus is
	authoritative, not the straw poll" and that "we make decisions
	by consensus, not majority" (P2195R2), and ISO defines consensus
	as a process that takes all views into account and reconciles
	conflicting arguments, not a count of hands (ISO/IEC Directives
	Part 1, clause 2.5.6).  The chair's authority is broad by
	design, and rightly so; a committee that decided technical
	questions by votes rather than expert judgment would be worse.

That is, I use my judgement as an expert.  That's all we can document.

> We'd be unwise to determine consensus by measuring who writes the most
> words (hi, folks), or with the angriest tone, or who has the most
> impressive job title at the biggest company, or who can shut down a
> discussion most coldly or derail it most effectively.
> 
> So tell the members of this community how _you_ measure it.  Put the
> burden on the critical and the concerned to find flaws in your method.

At least, I've documented how and why I've valued the feedback from each
one this (so-contentious) time.

If anyone wants to appeal, I'll be open to changing my mind based on new
technical reasons.


Cheers,
Alex

> Regards,
> Branden
> 
> [1]  I'm not sure WG14 uses the term "motions", and I haven't seen much
>      evidence that they use Robert's Rules of Order, with which
>      Commonwealth people are likely not familiar, let alone
>      non-Anglophones.



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

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

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

[Bruno Haible]

Hi Alejandro,

All proposed ISO C changes need to be evaluated according to (at least)
these three dimensions:

  * Benefit (for the community of C programmers),
  * Cost of adoption (for the community of C programmers),
  * Consistency.

Your previous proposal "alx-0097r1 - <memory.h>, the legitimate header for
memcpy(3) et al." evaluates like this, IMO:
  * Benefit: Small.
  * Cost of adoption: Huge
    (there are more than 700000 references to memcpy() alone in Debian sources
    [1]).
  * Consistency: Reasonable (you have explained why strncpy is actually a "mem"
    function).

This proposal [v2] is no longer for ISO C, but — if you want to teach the
community something by modifying the man pages — needs to be evaluated according
to the same criteria.
  * Benefit: None.
  * Cost of adoption: Moderate
    (because these 5 functions are not frequently used).
  * Consistency: Totally negative.
      - memmem() is a generalization of memchr(), therefore it belongs in the
        same header file, namely <string.h>.
      - memrchr() is an analogue to memchr(), therefore likewise it belongs in
        <string.h>.
      - mempcpy() is a variant of memcpy(), therefore likewise it belongs in
        <string.h>.
      - strndupa() is a variant of strndup() which is declared in <string.h>,
        therefore it belongs in <string.h> as well.

Please do us the favour to evaluate your proposals according to these
dimensions by yourself, before spreading them.

And, of course, for man page changes, consider the authoritative source.
For example, memfrob() exists only in glibc [2], therefore its authoritative
documentation is in the glibc manual [3], and it says "It is declared in
string.h." The man pages MUST say the same thing.

Thanks.

      Bruno

[1] https://codesearch.debian.net/search?q=%5Cbmemcpy%5Cb&literal=0
[2] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists
[3] https://sourceware.org/glibc/manual/2.44/html_node/Obfuscating-Data.html

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

> Date: 2026-08-02 00:22:37+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi Branden,
> 
> > Date: 2026-08-01 16:34:21-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> >
> > Hi Alex,
> > 
> > At 2026-08-01T19:09:36+0200, Alejandro Colomar wrote:
> > > Well, Keith Bostic wouldn't have suggested that I do this change, and
> > > Branden wouldn't be defending that it might make sense to make this
> > > change.
> > 
> > I'm flattered to be mentioned in the same breath as Keith Bostic!
> 
> :)
> 
> > > A vocal majority is not consensus.  Consensus would be if there were
> > > no significantly different or strongly opposed opinions to those of
> > > the majority.  Even my strong and sustained opposition against your
> > > opinion already means there's no consensus against.
> > 
> > "Consensus" is a word that gets abused a lot, because it has multiple
> > definitions.  To some people it means "unanimity".  To others, it means
> > a majority vote with potentially many abstentions but no (or
> > proportionally very few) negative votes.
> 
> Indeed.
> 
> > From reading WG14 minutes, I'm
> > vaguely aware that it has a rubric for reading the straw polls they take
> > when voting on N-papers and related motions.[1]  I invite a member to
> > cite a resource laying out their actual procedures.
> 
> WG14, like WG21, has a problem.  Consensus, these days, is taken as
> roughly a majority of votes.
> 
> With very few exceptions, here's the rule that guides consensus in straw
> polls during committee meetings:
> 
> 		// Consensus requires both
> 		//	y/(y+n)   >= 2/3
> 		//	n/(y+n+a) <= 1/4
> 
> Strong opposition is dismissed as long as the numbers are okay.  We even
> have a small program that performs that calculation and which we
> consult.
> 
> As a consequence, this is what happens (very interesting read):
> <https://isocpp.org/files/papers/P4238R0.pdf>.
> 
> A large number of NBs (national bodies), including mine, are going to
> vote against C++26, and as a consequence, it may be returned to WG21 for
> evaluation.  This means we won't have C++26 if this happens.
> 
> > I don't think I'm voicing a controversial view when I venture that
> > Michael Kerrisk administered the Linux man-pages with a more settled
> > view of the APIs it documents.  By that, I mean that he tended to update
> > its content with a retrospective view of matters that were no longer in
> > contention.  If some controversy brewed, he tended to omit it from
> > "coverage" in the documentary corpus until the contention resolved.
> 
> Yup.
> 
> > Your approach is a little different: you're more ready to give the
> > reader a view of live controversies and unsettled matters troubling the
> > C community where these intersect with the topics man-pages(7) covers.
> 
> Yup.
> 
> > Neither approach is better.  They're just different.
> 
> Yup.
> 
> > I think Sam is
> > right that people had many years to get used to Michael's approach.
> > From there it's a short--but logically unsound--step to associate
> > "familiar" with "better".
> 
> Yup.
> 
> > But, if you're going to document unresolved controversies, how do you
> > avoid putting a thumb on the scale?
> 
> Doing a lot of research.  Whatever I don't research myself, I still act
> like Michael, and tend to not step into.  But string and memory handling
> is something that has taken most of my time in the last 5 years or so.

In fact, I'd say I'm quite like Michael.  It's just that Michael was an
expert in other topics, more related to man2 and man7, and I'm more of
an expert in libc (man3).  Thus, Michael wrote quite a lot of somewhat-
opinionated paragraphs in man2 and man7, which for some reason didn't
trigger this amount of criticism (maybe because he added the text while
the pages were added, and thus it didn't come as revisionism).


Cheers,
Alex

> > One way is to solicit review of that coverage for even-handedness--I
> > do not say "neutrality".  List pros and cons of competing interfaces or
> > code idioms.
> 
> I do indeed get that.  Mark gave me feedback about memccpy(3) recently,
> which I've incorporated to my research.  That was the last issue I had
> with <string.h>, because memccpy(3) is something I've never seen in real
> correct use.  It seems Illumos is one of the places where they store
> that old knowledge.  It's good that those projects still exist and can
> be used to learn about our history.
> 
> Sam was concerned about not docuementing what standards say; and indeed,
> I'll make sure to document that (in STANDARDS, where it belongs; which
> I had already done, BTW).  Other than that, he was worried that I might
> be encoding an opinion, but I believe this is a technical judgement
> based on research, and not an opinion.  So, dismissed.
> 
> Joseph was concerned that this documentation would conflict with many
> documents saying that <memory.h> is deprecated.  Luckily, I've never
> seen such a document, so we can assume they don't exist (unless people
> show evidence).  I'll dismiss his negative vote, since his technical
> reasons are incorrect.  Also, <memory.h> is undoubtedly more portable 
> than a new <stdmem.h>.
> 
> It's also a bit Ironic that Joseph started with a strongly opinionated
> proposal: deprecating <memory.h> in glibc (breaking 8.9k uses in
> Debian).
> 
> Collin didn't comment, although by his support to Joseph's suggestion
> of deprecating <memory.h>, I guess he's against.  Since he didn't
> provide any new reasons, I guess it's more of Joseph's.  Already
> dismissed, then.
> 
> Nevin has an undeclared conflict of interest:  He is the author of a
> proposal for WG14 to remove strncpy(3).
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3935.htm>
> Also, he didn't really give any technical reasons; he just voted no.
> A vote without reasons is still heard, but easily dismissed.
> 
> Keith suggested doing this, by which I assume he's in favour.  He's
> certainly an expert in the topic, and I'd value his support.
> 
> I value Doug's opinion too, although he didn't show much technical
> reasons this time.  He was mostly concerned about changing string
> functions, but didn't clarify whether he was concerned about restoring
> <memory.h>.  Thus, I'd say I won't count that.
> 
> You seem to support the fact that something should be done, except that
> you may not entirely agree with the approach.  You've been a bit
> misguided by Joseph's concerns about <memory.h>, so I'll dismiss that
> part of your feedback as being just Joseph's --which I've already
> dismissed on technical grounds--.
> 
> Chris is concerned about my arbitrary separation, but I think his
> separation is also somewhat arbitrary.  I'll trust my instinct here.
> We're always in time to revise this.  In any case, this arbitrary
> distinction is better than the status quo.
> 
> Thus, with support from Keith, and no sustained opposition based on
> technical ground (Joseph didn't contest my response that absolutely no
> mainstream documents talk about <memory.h> being deprecated, and himself
> said that it's only *implicitly* deprecated), I should commit.
> 
> >  If you do that job correctly, _reasonable_ partisans of
> > the various contesting positions will find no cause to criticize.
> > (There will sometimes be fanboys who object to the "opposition" getting
> > any coverage at all.)
> > 
> > Further, with such lists you do a service to the engineer who must
> > select a means of solving the problem confronting them.  The engineer
> > often knows that problem better than anyone else does.
> > 
> > Next comes a trickier bit: what if you yourself get involved, even while
> > "wearing a different hat", in one of these live controversies?
> > 
> > Your first line of defense is your own ethical conscience.
> > 
> > Another, as I suggested earlier, is to solicit one or more volunteers to
> > serve as "deputy maintainers".  Prepare a list of man pages or sections
> > thereof upon which you are "conflicted out", and ask the deputies to
> > field all Linux man-pages business regarding those pages/sections while
> > you have business regarding those interfaces before a vendor libc and/or
> > the WG14 committee.  It will likely be obvious to you what vehicle can
> > communicate these areas of deputy maintenance--a man page!
> > 
> > I intuit that Michael had a hard time finding anyone to take the mantle
> > of Linux man-pages maintainership.  It's a huge job and demanded someone
> > of your unusual resources and energy.  By opening deputy positions that
> > are limited both in scope and in time, nobody need worry that they'll be
> > expected to eat the whole elephant.  If you find such volunteers, then
> > you'll also be spreading expertise and socializing personal investment
> > in the success of this project.  That's good management!
> 
> I have a mental list of people to whom I consult when I don't think
> I should make the decision alone.  The list isn't fixed, and varies
> wildly depending on the topics, but you can get an idea when I CC people
> in discussions.  You've been yourself quite some times.  :)
> 
> > Finally, to return to the question of consensus: a potential point of
> > development in Linux man-pages project governance is to _document how
> > you measure consensus_.
> 
> Nope.  I'll quote <https://isocpp.org/files/papers/P4238R0.pdf>:
> 
> 	2. How Consensus Is Supposed to Work
> 	WG21 decides by consensus, not by vote.  The chair, a
> 	subject-matter expert, weighs the arguments of every side.
> 	Where they can be reconciled, the chair reconciles them.  Where
> 	they cannot be reconciled, the chair decides, and may decide
> 	against the numerical majority.  This is deliberate: WG21's own
> 	guidance states that "the chair's determination of consensus is
> 	authoritative, not the straw poll" and that "we make decisions
> 	by consensus, not majority" (P2195R2), and ISO defines consensus
> 	as a process that takes all views into account and reconciles
> 	conflicting arguments, not a count of hands (ISO/IEC Directives
> 	Part 1, clause 2.5.6).  The chair's authority is broad by
> 	design, and rightly so; a committee that decided technical
> 	questions by votes rather than expert judgment would be worse.
> 
> That is, I use my judgement as an expert.  That's all we can document.
> 
> > We'd be unwise to determine consensus by measuring who writes the most
> > words (hi, folks), or with the angriest tone, or who has the most
> > impressive job title at the biggest company, or who can shut down a
> > discussion most coldly or derail it most effectively.
> > 
> > So tell the members of this community how _you_ measure it.  Put the
> > burden on the critical and the concerned to find flaws in your method.
> 
> At least, I've documented how and why I've valued the feedback from each
> one this (so-contentious) time.
> 
> If anyone wants to appeal, I'll be open to changing my mind based on new
> technical reasons.
> 
> 
> Cheers,
> Alex
> 
> > Regards,
> > Branden
> > 
> > [1]  I'm not sure WG14 uses the term "motions", and I haven't seen much
> >      evidence that they use Robert's Rules of Order, with which
> >      Commonwealth people are likely not familiar, let alone
> >      non-Anglophones.
> 
> 
> 
> -- 
> <https://www.alejandro-colomar.es>



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

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

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

[Alejandro Colomar]

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

Hi Bruno!

> Date: 2026-08-02 00:22:34+0200
> From: Bruno Haible <bruno@clisp.org>
>
> Hi Alejandro,
> 
> All proposed ISO C changes need to be evaluated according to (at least)
> these three dimensions:
> 
>   * Benefit (for the community of C programmers),
>   * Cost of adoption (for the community of C programmers),
>   * Consistency.
> 
> Your previous proposal "alx-0097r1 - <memory.h>, the legitimate header for
> memcpy(3) et al." evaluates like this, IMO:
>   * Benefit: Small.
>   * Cost of adoption: Huge
>     (there are more than 700000 references to memcpy() alone in Debian sources
>     [1]).

There's literally no change.  The proposal includes this:

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

Which means that <string.h> is still a valid provider of memcpy(3), and
thus absolutely no existing code breaks.

This is really a documentation change only.  libc implementations that
don't already have <memory.h> --i.e., Illumos gate, and gnulib, in the
POSIX-ish world-- will have to do some work, but users won't.

>   * Consistency: Reasonable (you have explained why strncpy is actually a "mem"
>     function).
> 
> This proposal [v2] is no longer for ISO C, but — if you want to teach the
> community something by modifying the man pages — needs to be evaluated according
> to the same criteria.
>   * Benefit: None.
>   * Cost of adoption: Moderate
>     (because these 5 functions are not frequently used).
>   * Consistency: Totally negative.
>       - memmem() is a generalization of memchr(), therefore it belongs in the
>         same header file, namely <string.h>.
>       - memrchr() is an analogue to memchr(), therefore likewise it belongs in
>         <string.h>.
>       - mempcpy() is a variant of memcpy(), therefore likewise it belongs in
>         <string.h>.
>       - strndupa() is a variant of strndup() which is declared in <string.h>,
>         therefore it belongs in <string.h> as well.

Indeed, I've decided to do the entire set of v1, except I'll add some
more text to NOTES documenting that <string.h> provides all of them too.

> Please do us the favour to evaluate your proposals according to these
> dimensions by yourself, before spreading them.

Sure!  Thanks!

> And, of course, for man page changes, consider the authoritative source.
> For example, memfrob() exists only in glibc [2], therefore its authoritative
> documentation is in the glibc manual [3], and it says "It is declared in
> string.h." The man pages MUST say the same thing.

Yes, in v3 (which I'll send soon), they'll say the same thing.  That is,
all the functions --standard or not-- will have text clarifying that the
functions are also provided in <string.h>.  This covers what glibc says.
What goes in the SYNOPSIS is something I'll diverge from glibc, but
that's fair game.

Thanks for the feedback!


Have a lovely night!
Alex

> Thanks.
> 
>       Bruno
> 
> [1] https://codesearch.debian.net/search?q=%5Cbmemcpy%5Cb&literal=0
> [2] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists
> [3] https://sourceware.org/glibc/manual/2.44/html_node/Obfuscating-Data.html
> 
> 
> 

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

[Alejandro Colomar]

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

Hi Keith,

> Date: 2026-08-01 15:22:49-0700
> From: Keith Bostic <keith@bostic.com>
>
> On Sat, Aug 1, 2026 at 10:09 AM Alejandro Colomar <alx@kernel.org> wrote:
> 
> 
> Well, Keith Bostic wouldn't have suggested that I do this change, and
> Branden wouldn't be defending that it might make sense to make this
> change.
> 
> 
> Since my name came up: I did suggest man page changes, and I should have
> been clearer about what I meant.

Thanks!

> I generally think innovation should happen in releases, in response to the
> user base. That’s the model with the better track record. Somebody ships
> something, users adopt it or they don’t, and the standards codify existing
> practice once it reaches consensus. When the standards bodies invent
> instead of codify, results have been uneven.

Fully agreed.

> So if glibc added <nonstring.h> tomorrow, that’s the system working. Ship
> it, let people vote with their code, and let the standard adopt if it wants.
> 
> But as I understand it, the man-pages project doesn’t control the code it
> documents. It describes glibc and the kernel, it doesn’t ship them. A
> documentation project changing how coding should work in a release it
> doesn’t control feels different to me. So, my opinion is the man pages
> shouldn’t be changing the standard includes.

Actually, the documentation is for the system, not the standard.  The
system does provide <memory.h>, and thus it's fair game to document it,
I believe.

> Advocating for better usage in the documentation is a different thing, and
> a good thing. The man pages can even go pretty hard, that’s their job:
> “Notice the include file is string.h. That’s an historic accident
> maintained for compatibility reasons; don’t let that fool you, this
> function doesn’t operate on strings.”

Indeed.  That's in essence what I'll do, with different wording.

The SYNOPSIS is the way of saying "don't let other sources fool you,
this function doesn't work on strings, and you should include the
system's <memory.h> to get it, which is compatible with all versions of
libc".

The NOTES section is the way of documenting "but the standard says
something different; let's ignore it".

	--- HEAD^:man/man3/strdupa.3
	+++ HEAD:man/man3/strdupa.3
	@@ -11,6 +11,10 @@ SYNOPSIS
	      #include <string.h>
	 
	      char *strdupa(const char *s);
	+
	+     #define _GNU_SOURCE  /* See feature_test_macros(7) */
	+     #include <memory.h>
	+
	      char *strndupa(size_t n;
			    const char s[n], size_t n);
	 
	@@ -48,6 +52,9 @@ STANDARDS
	 HISTORY
	      GNU.
	 
	+NOTES
	+     The following header also provides strndupa(): <string.h>.
	+
	 SEE ALSO
	      alloca(3), strdup(3), strndup(3)
	 
> That teaches the reader what the function actually does without relabeling
> where it lives. I think it’s roughly what Joseph is suggesting as well,
> aiming the clarification at the reader’s understanding rather than at the
> SYNOPSIS line.

I should probably expand the NOTES a little bit, to be more clear about
why we ignore the standard in the SYNOPSIS.


Have a lovely night!
Alex

> 
> —keith
> keith@bostic.com

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

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

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

[Bruno Haible]

Hi Alejandro,

> > Your previous proposal "alx-0097r1 - <memory.h>, the legitimate header for
> > memcpy(3) et al." evaluates like this, IMO:
> >   * Benefit: Small.
> >   * Cost of adoption: Huge
> >     (there are more than 700000 references to memcpy() alone in Debian sources
> >     [1]).
> 
> There's literally no change.  The proposal includes this:
> 
>     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>.
> 
> Which means that <string.h> is still a valid provider of memcpy(3), and
> thus absolutely no existing code breaks.

Still, for the next 10 years, C programmers would debate whether they should
#include <string.h> or #include <memory.h>. Different C programmers in the
same team will have different personal opinions. Thus, programmer team leads
will have to establish coding styles/guidelines which say which header to
include in this case.

This is one of the challenges of language design: Each time the language
offers several nearly equivalent ways of doing the same thing, different
coding styles and the need for team guidelines are the consequence.
C++ is particularly affected by this; Go hardly. Pushing C to become
like C++, in this respect, would not be a good move.

The cost of adoption for this proposal is thus still big.

> > And, of course, for man page changes, consider the authoritative source.
> > For example, memfrob() exists only in glibc [2], therefore its authoritative
> > documentation is in the glibc manual [3], and it says "It is declared in
> > string.h." The man pages MUST say the same thing.
> 
> Yes, in v3 (which I'll send soon), they'll say the same thing.  That is,
> all the functions --standard or not-- will have text clarifying that the
> functions are also provided in <string.h>.  This covers what glibc says.
> What goes in the SYNOPSIS is something I'll diverge from glibc, but
> that's fair game.

I don't agree with you that it's "fair game". The SYNOPSIS is the first
eye-catcher, often the only part that a programmer reads. It would be a
disgrace if the man page, in the SYNOPSIS, mentions a different header than
the authoritative source.

Bruno

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

[Alejandro Colomar]

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

Hi Bruno,

> Date: 2026-08-02 00:55:46+0200
> From: Bruno Haible <bruno@clisp.org>
>
[...]
> > Which means that <string.h> is still a valid provider of memcpy(3), and
> > thus absolutely no existing code breaks.
> 
> Still, for the next 10 years, C programmers would debate whether they should
> #include <string.h> or #include <memory.h>. Different C programmers in the
> same team will have different personal opinions. Thus, programmer team leads
> will have to establish coding styles/guidelines which say which header to
> include in this case.

I find that an acceptable result.  #include's aren't that important.
When reading code, the section of #include's is unimportant as long as
it works.

I don't expect existing code to change, so this is a matter of what will
happen in new files, or when a file is changed to newly use such a
function.

Among the stylistic discussions that can happen, this is the least of
our concerns.  Also, if this triggers a discussion of _why_ this
changed, we might have achieved something.

> This is one of the challenges of language design: Each time the language
> offers several nearly equivalent ways of doing the same thing, different
> coding styles and the need for team guidelines are the consequence.
> C++ is particularly affected by this; Go hardly. Pushing C to become
> like C++, in this respect, would not be a good move.

We have precedent in <stdint.h> and <inttypes.h>.  The world hasn't
fallen over our heads so far.  :)

Actually, <stdint.h> is just the tip of the ideberg.  size_t is provided
by 27 headers, if I counted well.  And there's plenty of such examples.
Another curious one is that there's something that's specified by ISO C
to be defined in <time.h>, and by POSIX to be defined by <sys/time.h>.
I don't remember what it was, but it was funny when I found out.

I've been involved for a few years in iwyu(1), contributing code for
dealing with the standard includes from libc, and while we had our share
of discussion of which headers are preferred for each symbol (we're some
pedants, of course), I've never heard that such discussions reached the
general public.  The general public just wants a tool that says which
are the right headers, and go with it.

> The cost of adoption for this proposal is thus still big.
> 
> > > And, of course, for man page changes, consider the authoritative source.
> > > For example, memfrob() exists only in glibc [2], therefore its authoritative
> > > documentation is in the glibc manual [3], and it says "It is declared in
> > > string.h." The man pages MUST say the same thing.
> > 
> > Yes, in v3 (which I'll send soon), they'll say the same thing.  That is,
> > all the functions --standard or not-- will have text clarifying that the
> > functions are also provided in <string.h>.  This covers what glibc says.
> > What goes in the SYNOPSIS is something I'll diverge from glibc, but
> > that's fair game.
> 
> I don't agree with you that it's "fair game". The SYNOPSIS is the first
> eye-catcher, often the only part that a programmer reads. It would be a
> disgrace if the man page, in the SYNOPSIS, mentions a different header than
> the authoritative source.

Some would question the fact that the glibc manual is the authoritative
source for glibc documentation.  :)

> Bruno


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

[Alejandro Colomar]

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

Hi Keith,

> Date: 2026-08-02 00:44:46+0200
> From: Alejandro Colomar <alx@kernel.org>
>
[...]
> > Advocating for better usage in the documentation is a different thing, and
> > a good thing. The man pages can even go pretty hard, that’s their job:
> > “Notice the include file is string.h. That’s an historic accident
> > maintained for compatibility reasons; don’t let that fool you, this
> > function doesn’t operate on strings.”
> 
[...]
> I should probably expand the NOTES a little bit, to be more clear about
> why we ignore the standard in the SYNOPSIS.

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

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

Cheers,
Alex

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

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

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

[Collin Funk]

Alejandro Colomar <alx@kernel.org> writes:

>> Still, for the next 10 years, C programmers would debate whether they should
>> #include <string.h> or #include <memory.h>. Different C programmers in the
>> same team will have different personal opinions. Thus, programmer team leads
>> will have to establish coding styles/guidelines which say which header to
>> include in this case.
>
> I find that an acceptable result.

But you aren't the only one who uses or references the man pages. From
this thread, many people are not happy with the change.

> #include's aren't that important. When reading code, the section of
> #include's is unimportant as long as it works.

In this case they won't "always work", hence your request that gnulib
and illumos make changes to accommodate your preferences.

>> I don't agree with you that it's "fair game". The SYNOPSIS is the first
>> eye-catcher, often the only part that a programmer reads. It would be a
>> disgrace if the man page, in the SYNOPSIS, mentions a different header than
>> the authoritative source.
>
> Some would question the fact that the glibc manual is the authoritative
> source for glibc documentation.  :)

I am not sure why it wouldn't be? It is what the glibc maintainers most
actively update. It isn't perfect of course, but it does contain quite a
lot of information:

    $ pdfinfo manual/libc.pdf  | grep '^Pages:'
    Pages:           1284

Collin

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

[Paul Eggert]

On 8/1/26 17:10, Alejandro Colomar wrote:
> #include's aren't that important.

But this whole thread is about #includes, no?

I would focus energy on areas of the manual where effort provides the 
most bang for the buck. As your remark suggests, this particular area is 
low priority. Also, given what I've seen in the thread so far, the 
proposed change could even yield a negative return overall.

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

[Alejandro Colomar]

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

Hi Collin,

> Date: 2026-08-01 16:26:18-0700
> From: Collin Funk <collin.funk1@gmail.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> >> Still, for the next 10 years, C programmers would debate whether they should
> >> #include <string.h> or #include <memory.h>. Different C programmers in the
> >> same team will have different personal opinions. Thus, programmer team leads
> >> will have to establish coding styles/guidelines which say which header to
> >> include in this case.
> >
> > I find that an acceptable result.
> 
> But you aren't the only one who uses or references the man pages. From
> this thread, many people are not happy with the change.
> 
> > #include's aren't that important. When reading code, the section of
> > #include's is unimportant as long as it works.
> 
> In this case they won't "always work", hence your request that gnulib
> and illumos make changes to accommodate your preferences.

I've now carefully documented that gnulib and Illumos don't provide this
header.  Thanks!


Have a lovely night!
Alex

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

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

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

[Alejandro Colomar]

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

Hi Paul,

> Date: 2026-08-01 18:29:13-0500
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> On 8/1/26 17:10, Alejandro Colomar wrote:
> > #include's aren't that important.
> 
> But this whole thread is about #includes, no?
> 
> I would focus energy on areas of the manual where effort provides the most
> bang for the buck. As your remark suggests, this particular area is low
> priority.

I wouldn't call it low priority or low bang for the buck.  What I mean
is that it's not a breaking change.

I believe education is important, and provides bang for the buck.  It's
not all about features.  The features are already there, but misused.


Have a lovely night!
Alex

> Also, given what I've seen in the thread so far, the proposed
> change could even yield a negative return overall.

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

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

proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform)

[G. Branden Robinson]

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

Hi Alex,

At 2026-08-02T01:24:28+0200, Alejandro Colomar wrote:
> > Date: 2026-08-02 00:44:46+0200
> > From: Alejandro Colomar <alx@kernel.org>
> >
> [...]
> > > Advocating for better usage in the documentation is a different
> > > thing, and a good thing. The man pages can even go pretty hard,
> > > that’s their job: “Notice the include file is string.h. That’s an
> > > historic accident maintained for compatibility reasons; don’t let
> > > that fool you, this function doesn’t operate on strings.”
> > 
> [...]
> > I should probably expand the NOTES a little bit, to be more clear
> > about why we ignore the standard in the SYNOPSIS.
> 
> I've put that text in a centralized place, in the memory.h(3head)
> manual page:
> 
> 	$ MANWIDTH=64 diffman-git HEAD
> 	--- HEAD^:man/man3head/memory.h.3
> 	+++ HEAD:man/man3head/memory.h.3
> 	@@ -10,6 +10,11 @@ SYNOPSIS
> 	      #include <memory.h>
> 	 
> 	 DESCRIPTION
> 	+     These functions are also provided in <string.h>, as speci‐
> 	+     fied by ISO C.  This is a historic accident maintained for
> 	+     compatibility reasons.  Don’t let that fool you; these
> 	+     functions don’t necessarily operate on strings.
> 	+

That's a heavy editorial slant.  I don't think it was a historical
accident; it was a historical "on purpose"[1], with which you disagree.
Here's a revision that goes a little less hard, favors active voice over
passive, and is shorter.

	+     ISO C mandates that <string.h> declare these functions.
	+     Be aware that they do not necessarily operate on strings.

> 	+STANDARDS
> 	+     BSD.

If you're tracking SVID in the Linux man-pages project, I would guess
that it was in the original SVID, which formalized/specified SVr2--but I
can't find online any version of SVID older than its Fourth Edition.

If you care about SVID, this point may bear further research.  Matt G.
of TUHS might have a line on older editions of SVID.

> 	+HISTORY
> 	+     The <memory.h> header file is the original one which was
> 	+     added in System V (1983), and was later adopted by 4.3BSD
> 	+     (1986).  It contained the original mem* functions.
> 	+
> 	+     C89 didn’t standardize this header file, and instead
> 	+     crammed all these functions in <string.h>, resulting in
> 	+     confusing programmers about the real purpose of these
> 	+     functions.

Again, you're going harder than you need to here.

I propose:

	+HISTORY
	+     System V (1983) introduced an initial set of mem*
	+     functions in a <memory.h> file.  4.3BSD (1986) adopted
	+     them.  C89 specified them in <string.h>.
	+
	+     The programmer bears the burden of selecting appropriate
	+     functions for operations on memory buffers (which may
	+     contain any bytes, including nulls) versus strings (which
	+     null bytes terminate).

If you like the foregoing, consider it:

Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com>

Regards,
Branden

[1] As one does with "all the glue", when one doesn't want a "major
    award" to be readily repaired...

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

the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>)

[G. Branden Robinson]

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

At 2026-08-02T01:36:28+0200, Alejandro Colomar wrote:
> > Date: 2026-08-01 18:29:13-0500
> > From: Paul Eggert <eggert@cs.ucla.edu>
> >
> > On 8/1/26 17:10, Alejandro Colomar wrote:
> > > #include's aren't that important.
> > 
> > But this whole thread is about #includes, no?
> > 
> > I would focus energy on areas of the manual where effort provides
> > the most bang for the buck. As your remark suggests, this particular
> > area is low priority.
> 
> I wouldn't call it low priority or low bang for the buck.  What I mean
> is that it's not a breaking change.
> 
> I believe education is important, and provides bang for the buck.
> It's not all about features.  The features are already there, but
> misused.

I'd like to underscore this point.  As I noted in my response to Doug,
the flagship book on C, as we all know, is stuck in 1988.  The throne is
vacant, with many pretenders, some with excellent cases for service as
regent.

But no head wears the crown.

And at the same time many C programmers are shy of consulting the formal
standard.  We can lament their lack of wisdom in doing so and in failing
to spin themselves up in standardese sufficiently to grapple with it.

But we can also throw 'em a bone.  To where shall they turn?

Sure, if they're in Emacs, they might go to glibc's Info manual.

But some people dislike Info, and some people use a different libc.

So what remains for the motley crew left behind?

The man pages.

I think people come to the Linux man-pages in part to learn C.  When I
was starting out, long ago, I wondered why there wasn't a man page for
the language itself.  Years later, I learned that there once sort of had
been, in the 1970s.  It was Ritchie's "C Reference Manual".[1]

But it wasn't on any Unix machine I had access to.

Why not?

Because Prentice-Hall didn't want it there.  And still don't, I guess.

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/cman

Maybe education is not a job the Linux man-pages project _should_ have,
but it is one that has been thrust upon it.

Regards,
Branden

[1] Not a man page, but you could render it intelligibly with nroff.

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

Re: proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-08-01 18:53:32-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> At 2026-08-02T01:24:28+0200, Alejandro Colomar wrote:
> > > Date: 2026-08-02 00:44:46+0200
> > > From: Alejandro Colomar <alx@kernel.org>
> > >
> > [...]
> > > > Advocating for better usage in the documentation is a different
> > > > thing, and a good thing. The man pages can even go pretty hard,
> > > > that’s their job: “Notice the include file is string.h. That’s an
> > > > historic accident maintained for compatibility reasons; don’t let
> > > > that fool you, this function doesn’t operate on strings.”
> > > 
> > [...]
> > > I should probably expand the NOTES a little bit, to be more clear
> > > about why we ignore the standard in the SYNOPSIS.
> > 
> > I've put that text in a centralized place, in the memory.h(3head)
> > manual page:
> > 
> > 	$ MANWIDTH=64 diffman-git HEAD
> > 	--- HEAD^:man/man3head/memory.h.3
> > 	+++ HEAD:man/man3head/memory.h.3
> > 	@@ -10,6 +10,11 @@ SYNOPSIS
> > 	      #include <memory.h>
> > 	 
> > 	 DESCRIPTION
> > 	+     These functions are also provided in <string.h>, as speci‐
> > 	+     fied by ISO C.  This is a historic accident maintained for
> > 	+     compatibility reasons.  Don’t let that fool you; these
> > 	+     functions don’t necessarily operate on strings.
> > 	+
> 
> That's a heavy editorial slant.  I don't think it was a historical
> accident; it was a historical "on purpose"[1], with which you disagree.

[pasted [1] here]
> [1] As one does with "all the glue", when one doesn't want a "major
>     award" to be readily repaired...

The C89 Rationale document doesn't document this as an intentional
change (or even as a change at all).
<https://www.open-std.org/jtc1/sc22/wg14/www/C89Rationale.pdf>

I'd certainly be interested in hearing first-hand information,
if anyone has it.  Maybe Keith would be the best candidate for that.

> Here's a revision that goes a little less hard, favors active voice over
> passive, and is shorter.
> 
> 	+     ISO C mandates that <string.h> declare these functions.
> 	+     Be aware that they do not necessarily operate on strings.

I'll think about it.

> 
> > 	+STANDARDS
> > 	+     BSD.
> 
> If you're tracking SVID in the Linux man-pages project, I would guess
> that it was in the original SVID, which formalized/specified SVr2--but I
> can't find online any version of SVID older than its Fourth Edition.

Here's an online copy of SVID Issue 2:
<https://bitsavers.org/pdf/att/unix/SVID/System_V_Interface_Definition_Issue_2_Volume_1_1986.pdf>
It does indeed standardize <memory.h>.

I don't know of any copy of SVID Issue 1.

SVID is a withdrawn standard (having been superseded by the SUS/POSIX
standards, Issue 8 in the most recent revision), and thus not
appropriate for STANDARDS.  It'd be however appropriate for HISTORY.
However, the SVID 1 corresponds to SVr2 (1985), so that's actually too
late for this.  In HISTORY, I've documented this as SysV (maybe we
should coin SVr1?  It doesn't exist in standards(7), but it'd be
reasonable).

At the moment, I have it as:

	STANDARDS
	     BSD.

	HISTORY
	     SysV, 4.3BSD.

		...

Also, we don't document the SVID documents in HISTORY, because we
document the corresponding revision of SysV.

Interestingly, POSIX.1-1988 already moved everything to <string.h>
(C89 was almost finalized by then) and doesn't contain any references to
<memory.h>, as if it had never existed.
<https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-1.pdf>
I'd be curious to see whether XPG Issue 3 still kept <memory.h> (but
I suspect it won't, since it derives from POSIX.1-1988).
SVID Third Edition curiously removed any mentions of <memory.h>, as if
it had never existed (just like POSIx.1-1988).
<https://archive.org/details/systemvinterface0001unse/page/n149/mode/1up?q=memory.h>

(For anyone reading and wondering about the incestuous relationship of
 these old standards, here's a useful rough sketch I did some time ago):
<https://lore.kernel.org/linux-man/aWwzhLaG_aehhWOG@devuan/>

> If you care about SVID, this point may bear further research.  Matt G.
> of TUHS might have a line on older editions of SVID.

I'd be interesting to have a copy of those, for sure.  I am aware of
the copies of Issue 2 and Third Edition I linked above, but I'd
certainly be interested in a copy of Issue 1.  XPG 3 would also be nice.

> > 	+HISTORY
> > 	+     The <memory.h> header file is the original one which was
> > 	+     added in System V (1983), and was later adopted by 4.3BSD
> > 	+     (1986).  It contained the original mem* functions.
> > 	+
> > 	+     C89 didn’t standardize this header file, and instead
> > 	+     crammed all these functions in <string.h>, resulting in
> > 	+     confusing programmers about the real purpose of these
> > 	+     functions.
> 
> Again, you're going harder than you need to here.
> 
> I propose:
> 
> 	+HISTORY
> 	+     System V (1983) introduced an initial set of mem*
> 	+     functions in a <memory.h> file.  4.3BSD (1986) adopted
> 	+     them.  C89 specified them in <string.h>.

I like part of this paragraph.

> 	+     The programmer bears the burden of selecting appropriate
> 	+     functions for operations on memory buffers (which may
> 	+     contain any bytes, including nulls) versus strings (which
> 	+     null bytes terminate).

I'm not convinced.

> 
> If you like the foregoing, consider it:
> 
> Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com>

I'll probably modify it and note it as

	Suggested-by: ...


Cheers,
Alex

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

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

Re: the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-08-01 19:08:33-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> At 2026-08-02T01:36:28+0200, Alejandro Colomar wrote:
> > > Date: 2026-08-01 18:29:13-0500
> > > From: Paul Eggert <eggert@cs.ucla.edu>
> > >
> > > On 8/1/26 17:10, Alejandro Colomar wrote:
> > > > #include's aren't that important.
> > > 
> > > But this whole thread is about #includes, no?
> > > 
> > > I would focus energy on areas of the manual where effort provides
> > > the most bang for the buck. As your remark suggests, this particular
> > > area is low priority.
> > 
> > I wouldn't call it low priority or low bang for the buck.  What I mean
> > is that it's not a breaking change.
> > 
> > I believe education is important, and provides bang for the buck.
> > It's not all about features.  The features are already there, but
> > misused.
> 
> I'd like to underscore this point.  As I noted in my response to Doug,
> the flagship book on C, as we all know, is stuck in 1988.  The throne is
> vacant, with many pretenders, some with excellent cases for service as
> regent.

In fact, the throne might currently fall in the Linux man-pages project.
While not being a blood heir of the Unix standards, it has become a
de-facto standard.

After all, both POSIX and C89 in one way or the other derive from the
Unix and System V manual pages (you can see it in their structure and
formatting).  Unix and System V were the largest systems of their age,
and GNU+Linux is currently in that position.  It's natural that its
manual pages are the current de-facto standard (no, not the texinfo
docs).

> But no head wears the crown.
> 
> And at the same time many C programmers are shy of consulting the formal
> standard.  We can lament their lack of wisdom in doing so and in failing
> to spin themselves up in standardese sufficiently to grapple with it.
> 
> But we can also throw 'em a bone.  To where shall they turn?
> 
> Sure, if they're in Emacs, they might go to glibc's Info manual.
> 
> But some people dislike Info, and some people use a different libc.

Michael was wise to document different libc's, including the BSDs, in
the manual pages, which is why they've become a standard.  If he had
limited to just glibc and Linux, it might not have been the case.

> So what remains for the motley crew left behind?
> 
> The man pages.

Indeed.

> I think people come to the Linux man-pages in part to learn C.  When I
> was starting out, long ago, I wondered why there wasn't a man page for
> the language itself.  Years later, I learned that there once sort of had
> been, in the 1970s.  It was Ritchie's "C Reference Manual".[1]

Hmmm, indeed, I believe that is the place to have it.  It doesn't make
much sense to document only part of the language in the pages but not
all of it.  FWIW, I've been documenting attributes and operators in the
manual pages recently.  We're closing the gap.

> But it wasn't on any Unix machine I had access to.
>
> Why not?
> 
> Because Prentice-Hall didn't want it there.  And still don't, I guess.
> 
> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/cman

Hmmm.  Is there any copy of that?

> Maybe education is not a job the Linux man-pages project _should_ have,

I don't see why.  In fact, I believe it's its ultimate job.

If documentation for a car was an aseptic piece of text describing
it mechanically but not saying how to use it, it wouldn't be much good.
It doesn't need to teach you how to drive (that's for driving schools),
but it certainly must educate the driver about the limitations of the
car, such as "this vehicle can lift from the ground if you drive at
300 mph, don't reach this speed".  Or "if you have a lateral hit, the
airbag won't protect you".

Same happens here.


Cheers,
Alex

> but it is one that has been thrust upon it.
> 
> Regards,
> Branden
> 
> [1] Not a man page, but you could render it intelligibly with nroff.



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

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

Re: proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform)

[Alejandro Colomar]

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

> Date: 2026-08-02 02:27:44+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> > Date: 2026-08-01 18:53:32-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> >
> > At 2026-08-02T01:24:28+0200, Alejandro Colomar wrote:
[...]
> > > 	 DESCRIPTION
> > > 	+     These functions are also provided in <string.h>, as speci‐
> > > 	+     fied by ISO C.  This is a historic accident maintained for
> > > 	+     compatibility reasons.  Don’t let that fool you; these
> > > 	+     functions don’t necessarily operate on strings.
> > > 	+
> > 
> > That's a heavy editorial slant.  I don't think it was a historical
> > accident; it was a historical "on purpose"[1], with which you disagree.
> 
> [pasted [1] here]
> > [1] As one does with "all the glue", when one doesn't want a "major
> >     award" to be readily repaired...
> 
> The C89 Rationale document doesn't document this as an intentional
> change (or even as a change at all).
> <https://www.open-std.org/jtc1/sc22/wg14/www/C89Rationale.pdf>
> 
> I'd certainly be interested in hearing first-hand information,
> if anyone has it.  Maybe Keith would be the best candidate for that.

Actually, s/accident/mistake/ is more correct.  It was most likely done
on purpose, even if unaware of the consequences it would have.  That's
not an accident but a mistake.


Cheers,
Alex

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

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

Re: the Linux man-pages as an educational tool

[Collin Funk]

Alejandro Colomar <alx@kernel.org> writes:

>> I'd like to underscore this point.  As I noted in my response to Doug,
>> the flagship book on C, as we all know, is stuck in 1988.  The throne is
>> vacant, with many pretenders, some with excellent cases for service as
>> regent.
>
> In fact, the throne might currently fall in the Linux man-pages project.
> While not being a blood heir of the Unix standards, it has become a
> de-facto standard.

I don't think anyone is arguing whether or not man-pages is an
educational tool. The argument is whether it should educate based on
current standards, or the maintainers preferences.

Collin

Re: the Linux man-pages as an educational tool

[G. Branden Robinson]

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

Hi Collin,

At 2026-08-01T18:04:05-0700, Collin Funk wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> >> I'd like to underscore this point.  As I noted in my response to
> >> Doug, the flagship book on C, as we all know, is stuck in 1988.
> >> The throne is vacant, with many pretenders, some with excellent
> >> cases for service as regent.
> >
> > In fact, the throne might currently fall in the Linux man-pages
> > project.  While not being a blood heir of the Unix standards, it has
> > become a de-facto standard.
> 
> I don't think anyone is arguing whether or not man-pages is an
> educational tool. The argument is whether it should educate based on
> current standards, or the maintainers preferences.

There are always going to be matters that a relevant standards body
hasn't resolved.  Its work would be trivial if there weren't!

I think what the Linux man-pages community is negotiating here is a pair
of related questions.

1.  Should the Linux man-pages make _any_ representations that are not
    supported by a formal standard?

2.  If so, what are the boundaries of its editorial authority?

3.  If not, hard luck for the Linux kernel, eh?

It's easy to say, "I don't like what Alex is doing with xyz(3)."  What's
harder is to articulate a reasonable-sounding, defensible principle that
should restrain him from doing so.

As Kant said:

"Act only according to that maxim whereby you can at the same time will
that it should become a universal law."

https://existentialcomics.com/comic/293

Regards,
Branden

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

Re: the Linux man-pages as an educational tool

[Alejandro Colomar]

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

Hi Collin,

> Date: 2026-08-01 18:04:05-0700
> From: Collin Funk <collin.funk1@gmail.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> >> I'd like to underscore this point.  As I noted in my response to Doug,
> >> the flagship book on C, as we all know, is stuck in 1988.  The throne is
> >> vacant, with many pretenders, some with excellent cases for service as
> >> regent.
> >
> > In fact, the throne might currently fall in the Linux man-pages project.
> > While not being a blood heir of the Unix standards, it has become a
> > de-facto standard.
> 
> I don't think anyone is arguing whether or not man-pages is an
> educational tool. The argument is whether it should educate based on
> current standards, or the maintainers preferences.

I'm not innovating if I say that the standards are mostly ignored.
Actually, I am more in the side of following the standards as much as
possible and appropriate (but not more) on average.

This is just a case where educating on the current standards is done by
1) documenting at the bottom of the manual what the standard says, and
2) recommending to ignore it because it's bad.  When the standards are
bad, this is appropriate course.

The manual pages should certainly educate about reality, and standards
are only secondary to that.

This reminds me of realloc(3).  That's a perfect example of educating
based on current (and withdrawn) standards.  And the education might
very well consist of saying "don't listen to the standards in this case;
they're bad for you".

I expect we'll be able to fix realloc(p,0) eventually, and Microsoft is
working with me on that.


STANDARDS
	...

   realloc(p, 0)
     The  behavior of realloc(p, 0) in glibc doesn’t conform to
     any of C99, C11, POSIX.1‐2001, POSIX.1‐2004, POSIX.1‐2008,
     POSIX.1‐2013,  POSIX.1‐2017,  or  POSIX.1‐2024.   The  C17
     specification  was changed to make it conforming, but that
     specification made it impossible to write code that  reli‐
     ably  determines if the input pointer is freed after real‐
     loc(p, 0), and C23 changed it again to make this undefined
     behavior, acknowledging that  the  C17  specification  was
     broad enough, so that undefined behavior wasn’t worse than
     that.

     reallocarray() suffers the same issues in glibc.

     musl  libc  and  the BSDs conform to all versions of ISO C
     and POSIX.1.

     gnulib provides the realloc‐posix module,  which  provides
     wrappers  realloc() and reallocarray() that conform to all
     versions of ISO C and POSIX.1.

     There’s a proposal to standardize the BSD behavior: https:
     //www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt.

HISTORY
	...

   realloc(p, 0)
     C89 was ambiguous in its specification of  realloc(p,  0).
     C99 partially fixed this.

     The  original implementation in glibc would have been con‐
     forming to C99.  However, and ironically, trying to comply
     with C99 before the standard was released,  glibc  changed
     its  behavior  in glibc 2.1.1 into something that ended up
     not conforming to the final C99 specification (but this is
     debated, as the wording of the standard seems self‐contra‐
     dicting).

...

BUGS
     Programmers  would  naturally  expect  by  induction  that
     realloc(p, size)  is  consistent  with  free(p)  and  mal‐
     loc(size),  as  that  is the behavior in the general case.
     This is not explicitly required by  POSIX.1‐2024  or  C11,
     but  all  conforming  implementations  are consistent with
     that.

     The glibc implementation of realloc()  is  not  consistent
     with  that,  and as a consequence, it is dangerous to call
     realloc(p, 0) in glibc.

     A  trivial  workaround  for  glibc  is   calling   it   as
     realloc(p, size?size:1).

     The  workaround for reallocarray() in glibc ——which shares
     the         same          bug——          would          be
     reallocarray(p, n?n:1, size?size:1).


Have a lovely night!
Alex

> 
> Collin

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

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

Re: the Linux man-pages as an educational tool

[Collin Funk]

Alejandro Colomar <alx@kernel.org> writes:

> I'm not innovating if I say that the standards are mostly ignored.
> Actually, I am more in the side of following the standards as much as
> possible and appropriate (but not more) on average.
>
> This is just a case where educating on the current standards is done by
> 1) documenting at the bottom of the manual what the standard says, and
> 2) recommending to ignore it because it's bad.  When the standards are
> bad, this is appropriate course.

But myself and likely many others who have commented on this thread do
not agree that strings.h is a bad name. Or that general memory related
functions, which are used on strings a large portion of the time, need a
separate header.

In one of your original messages you mentioned the following:

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

Then, in another you said:

> I find that an acceptable result.  #include's aren't that important.
> When reading code, the section of #include's is unimportant as long as
> it works.

If I concede that "#include's aren't that important", then strncpy still
exists and still looks like a function that should be used on
strings. So, we have still have the same problem unaddressed, right?
People will still use the function and write bugs.

> The manual pages should certainly educate about reality, and standards
> are only secondary to that.

The current reality and standards are fully in alignment here. memcpy et
al. have been defined in string.h since before I was born. Anyone who
knows of memory.h knows that they can just do s/memory/string/ and make
their code look more recent. Anyone who doesn't know about memory.h will
be confused why the man-pages tell them to use a different header than
they have used for decades. New programmers will follow those
instructions and find their code breaks on illumos, when it really
shouldn't.

Collin

Re: the Linux man-pages as an educational tool

[Alejandro Colomar]

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

Hi Collin,

> Date: 2026-08-01 18:49:03-0700
> From: Collin Funk <collin.funk1@gmail.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > I'm not innovating if I say that the standards are mostly ignored.
> > Actually, I am more in the side of following the standards as much as
> > possible and appropriate (but not more) on average.
> >
> > This is just a case where educating on the current standards is done by
> > 1) documenting at the bottom of the manual what the standard says, and
> > 2) recommending to ignore it because it's bad.  When the standards are
> > bad, this is appropriate course.
> 
> But myself and likely many others who have commented on this thread do
> not agree that strings.h is a bad name. Or that general memory related
> functions, which are used on strings a large portion of the time, need a
> separate header.

This is an opinion, which I respect, but don't agree with.

The vocal many people with that opinion have had 37 years to show how
the solution to string handling bugs was a different one.

I've done my research, and am convinced that this is an unintrusive
partial solution.  As the ultimate responsible of this documentation
project, I'll commit to this solution.  Time will tell whether I am
wrong.  I think string handling is already so messed in people's heads,
that at worst this solution won't do any noticeable good or bad, and at
best it might put an end to the problem.

> In one of your original messages you mentioned the following:
> 
> > 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.
> 
> Then, in another you said:
> 
> > I find that an acceptable result.  #include's aren't that important.
> > When reading code, the section of #include's is unimportant as long as
> > it works.
> 
> If I concede that "#include's aren't that important",

That sentence was in context.  #include's aren't that important in code.
They are important in documentation and education (as I replied to
Paul).

> then strncpy still
> exists and still looks like a function that should be used on
> strings.

The documentation part (including the global header classification,
which appears in the SYNOPSIS) is what makes (or should make) it not
look like a function that should be used on strings.

The name should also be part of that, but that ship sailed.  We could
actually also attempt at fixing the name, like the Linux kernel has
done, but that's a different topic.

> So, we have still have the same problem unaddressed, right?
> People will still use the function and write bugs.
> 
> > The manual pages should certainly educate about reality, and standards
> > are only secondary to that.
> 
> The current reality and standards are fully in alignment here. memcpy et
> al. have been defined in string.h since before I was born.

And they have also been defined in <memory.h> since before you and I
were born.

> Anyone who
> knows of memory.h knows that they can just do s/memory/string/ and make
> their code look more recent. Anyone who doesn't know about memory.h will
> be confused why the man-pages tell them to use a different header than
> they have used for decades.

That's why I've documented the reason in memory.h(3head).

> New programmers will follow those
> instructions and find their code breaks on illumos, when it really
> shouldn't.

I hope Illumos adds <memory.h>.  Also, I don't expect new programmers to
be exactly the kind of programmers that use Illumos.

> Collin


Have a lovely day!
Alex

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

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

Re: the Linux man-pages as an educational tool

[Alejandro Colomar]

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

Hi Collin,

> > Date: 2026-08-01 18:49:03-0700
> > From: Collin Funk <collin.funk1@gmail.com>
> >
> > But myself and likely many others who have commented on this thread do
> > not agree that strings.h is a bad name. Or that general memory related
> > functions, which are used on strings a large portion of the time, need a
> > separate header.

BTW, this typo reminds me that we have some more evidence.  <strings.h>
has existed for a long time in parallel to <string.h>, and some
functions are documented as being provided by it instead of by
<string.h>.  An example is strcasecmp(3).

In practice, both <string.h> and <strings.h> provide strcasecmp(3):

	alx@devuan:~/tmp$ cat s.c 
	#include <string.h>

	int
	main(void)
	{
		void *p = strcasecmp;
	}
	alx@devuan:~/tmp$ gcc -Wall -Wextra -Wno-unused s.c 
	alx@devuan:~/tmp$ 

Every now and then, people wonder about this non-standard header file,
but no cats were harmed by that.  Claiming that <memory.h> would be much
different is unreasonable, IMO.


Cheers,
Alex

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

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

Re: the Linux man-pages as an educational tool

[Alejandro Colomar]

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

> Date: 2026-08-02 03:15:43+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> > Date: 2026-08-01 18:04:05-0700
> > From: Collin Funk <collin.funk1@gmail.com>
> >
> > Alejandro Colomar <alx@kernel.org> writes:
> > 
[...]
> > 
> > I don't think anyone is arguing whether or not man-pages is an
> > educational tool. The argument is whether it should educate based on
> > current standards, or the maintainers preferences.
> 
> I'm not innovating if I say that the standards are mostly ignored.
> Actually, I am more in the side of following the standards as much as
> possible and appropriate (but not more) on average.
> 
> This is just a case where educating on the current standards is done by
> 1) documenting at the bottom of the manual what the standard says, and
> 2) recommending to ignore it because it's bad.  When the standards are
> bad, this is appropriate course.
> 
> The manual pages should certainly educate about reality, and standards
> are only secondary to that.
> 
> This reminds me of realloc(3).  That's a perfect example of educating
> based on current (and withdrawn) standards.  And the education might
> very well consist of saying "don't listen to the standards in this case;
> they're bad for you".

And let me expand on this.  realloc(p,0) is not just example and
precedent of how documentation *must* go against the standards when
appropriate.  It's also an example of how the manual pages must and will
go against the partial specification of glibc's official manual.

We would do programmers a disservice if the manual pages limited to
mirror what glibc's manual says.

Where the glibc documentation doesn't document its own perils, we must
deviate from that, and document them clearly.


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

[Steve Summit]

I'm just a lurker, but let me offer my perspective on this.

Header files in C and C++ are in large part a nuisance and a
historical relic.  If I call function x, I must include header
<y.h>.  The mapping between x and y is partly sensible, but
partly arbitrary.

Since I program in C and/or C++ every day, I can usually remember
that mapping, but when I can't, I immediately check the man page,
and I'm glad that (unlike in the old days) the Synopsis section
always reminds me which header to include.

Although I said header files are a nuisance, in one key respect
they're less of a nuisance than they used to be, because *the C
and C++ standards standardize them*.  This is a huge, huge win.
Back in the day you never knew if you could or should use
reasonable-looking headers like <memory.h> or <malloc.h>.  But
today, it's a no-brainer.  There's one right answer.  If I use
the Standard header in my code, and my code fails to compile
under some brain-dead compiler tomorrow, it's that compiler's
fault, not mine.  I don't care a bit whether the Standard's
mappings do or don't make sense; the fact that they're standard
trumps anything else.

Now, this is one man's perspective, and I concede that I'm not
an average C or C++ programmer, either.  Me, I could check the
Standard, because I have PDF copies of every version of the C
Standard right here on my laptop, but for this sort of question I
typically don't, because typing "man memset" is so much quicker.
I don't know what the average programmer does, but I would
heartily advocate for a high-quality man page to give the Right
answer, where the Right answer for standard functions is
precisely what the Standard says.

Now, there are always interesting arguments to be had about which
of the library functions still hold their weight today, which of
them might be deprecated or replaced with something newer, and
how to educate users about evolving best practices.  Certainly,
today, strncpy and strncat are the new gets.  (As it happens,
I've been spending real time just in the past few weeks coping
with the fact that not every Linux C compiler I use ships with
a glibc that supports strlcpy and strlcat.)

But with that said, the place for those "interesting arguments"
is not a man page!  Man pages are supposed to be maximally
pithy.  Just the facts, ma'am.

Finally, I really don't think that the the mapping between
function x and header <y.h>, a mapping which I characterized as
somewhat arbitrary, is something that the average programmer pays
that much attention to.  If strncpy or memset is to be found in
a header called <string.h>, that doesn't tell us that these
functions operate on strings, any more than ssprintf appearing in
<stdio.h> implies that ssprintf does I/O.  So let's put the
arguing, and the opinionating, and the educating, somewhere else,
and have the man pages document (nay, recommend) precisely the
headers that the Standard(s) say are standard.

Steve Summit

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Steve,

> Date: 2026-08-02 08:52:04-0400
> From: Steve Summit <scs@eskimo.com>
>
[...]
> Certainly,
> today, strncpy and strncat are the new gets.

This is deeply incorrect.

gets(3) is a function that can't possibly be used safely.

strncpy(3) is a fine function for copying a string into a fixed-width
buffer.  strncat(3) is a fine function for appending a
[[gnu::nonstring]] to a string.  strncpy/cat(3) are bad when they are
misused, just like a screwdriver is bad for hammering nails.

gets(3) is not that.

This is something that even most of the people disagreeing to this
proposed change agree with.

> (As it happens,
> I've been spending real time just in the past few weeks coping
> with the fact that not every Linux C compiler I use ships with
> a glibc that supports strlcpy and strlcat.)

strlcpy/cat(3) have their own issues, although admittedly a DoS is
better than a buffer overflow.

Ideally, you should be looking for strscpy(9); but you should write it
yourself, because it's not provided by any libraries.

> But with that said, the place for those "interesting arguments"
> is not a man page!  Man pages are supposed to be maximally
> pithy.  Just the facts, ma'am.

"The facts" is more subjective than it seems at first glance.

Just some examples of manual pages before I touched them, to show that
I'm not even innovating.  Maybe because I CC people I know disagree with
me, I get more vocal opposition, I guess.

Here's part of str[n]cpy(3) well before I got involved in the project.

	DESCRIPTION
	     The strcpy() function copies the string pointed to by src,
	     including  the terminating null byte ('\0'), to the buffer
	     pointed to by dest.  The strings may not overlap, and  the
	     destination  string  dest  must be large enough to receive
	     the copy.  Beware of buffer overruns!  (See BUGS.)

	     The strncpy() function is similar, except that at  most  n
	     bytes  of  src  are  copied.  Warning: If there is no null
	     byte among the first n bytes of src, the string placed  in
	     dest will not be null‐terminated.

	     If  the length of src is less than n, strncpy() writes ad‐
	     ditional null bytes to dest to ensure that a  total  of  n
	     bytes are written.

	     A simple implementation of strncpy() might be:

		 char *
		 strncpy(char *dest, const char *src, size_t n)
		 {
		     size_t i;

		     for (i = 0; i < n && src[i] != '\0'; i++)
			 dest[i] = src[i];
		     for ( ; i < n; i++)
			 dest[i] = '\0';

		     return dest;
		 }
	NOTES
	     Some  programmers consider strncpy() to be inefficient and
	     error prone.  If the programmer knows (i.e., includes code
	     to test!)  that the size  of  dest  is  greater  than  the
	     length of src, then strcpy() can be used.

	     One  valid  (and intended) use of strncpy() is to copy a C
	     string to a fixed‐length buffer while ensuring  both  that
	     the  buffer is not overflowed and that unused bytes in the
	     destination buffer are zeroed out (perhaps to prevent  in‐
	     formation leaks if the buffer is to be written to media or
	     transmitted  to another process via an interprocess commu‐
	     nication technique).

	     If there is no terminating null byte in the first n  bytes
	     of src, strncpy() produces an unterminated string in dest.
	     If  buf has length buflen, you can force termination using
	     something like the following:

		 if (buflen > 0) {
		     strncpy(buf, str, buflen - 1);
		     buf[buflen - 1]= '\0';
		 }

	     (Of course, the above technique ignores the fact that,  if
	     src  contains  more  than buflen - 1 bytes, information is
	     lost in the copying to dest.)

	   strlcpy()
	     Some systems (the BSDs, Solaris, and others)  provide  the
	     following function:

		 size_t  strlcpy(char  *dest,  const  char *src, size_t
	     size);

	     This function is similar to strncpy(), but  it  copies  at
	     most  size-1 bytes to dest, always adds a terminating null
	     byte, and does not pad the destination with (further) null
	     bytes.  This function fixes some of the problems  of  str‐
	     cpy()  and strncpy(), but the caller must still handle the
	     possibility of data loss if size is too small.  The return
	     value of the function is the length of src,  which  allows
	     truncation  to  be easily detected: if the return value is
	     greater than or equal to size,  truncation  occurred.   If
	     loss of data matters, the caller must either check the ar‐
	     guments  before  the  call,  or  test  the function return
	     value.  strlcpy() is not present in glibc and is not stan‐
	     dardized by POSIX, but  is  available  on  Linux  via  the
	     libbsd library.

	BUGS
	     If  the  destination  string  of  a  strcpy() is not large
	     enough, then anything might  happen.   Overflowing  fixed‐
	     length  string buffers is a favorite cracker technique for
	     taking complete control of the machine.  Any time  a  pro‐
	     gram reads or copies data into a buffer, the program first
	     needs to check that there’s enough space.  This may be un‐
	     necessary if you can show that overflow is impossible, but
	     be  careful:  programs  can get changed over time, in ways
	     that may make the impossible possible.

You may have thought that the manual pages have never been opinionated
before, and that they were strict about containing facts.  That's never
been true, though.  You may or may not agree with the previous
non-facts, but that doesn't make them more valid.

> Finally, I really don't think that the the mapping between
> function x and header <y.h>, a mapping which I characterized as
> somewhat arbitrary, is something that the average programmer pays
> that much attention to.  If strncpy or memset is to be found in
> a header called <string.h>, that doesn't tell us that these
> functions operate on strings,

That contradicts explicit claims by programmers in CC in this thread,
who have complained during code review (some months ago) that if
strncpy(3) is in <string.h>, then it must be because it's for copying
strings, and that I must thus be wrong rejecting code using it for
copying strings.

> any more than ssprintf appearing in
> <stdio.h> implies that ssprintf does I/O.  So let's put the
> arguing, and the opinionating, and the educating, somewhere else,
> and have the man pages document (nay, recommend) precisely the
> headers that the Standard(s) say are standard.


Have a lovely day!
Alex

> Steve Summit
> 

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

[Steve Summit]

Alejandro wrote:
>> Certainly, today, strncpy and strncat are the new gets.
>
> This is deeply incorrect.

That was a side point, but to clarify what I meant:

Once upon a time (and still today), it's a reasonable thing to say:

	Never use gets.  Don't worry if you don't understand the
	issue, don't worry if you heard someone say there's an
	obscure circumstance under which it might be useful,
	just don't ever use it; pretend it doesn't exist.

Today I think it's equally reasonable to say:

	Never use strncpy and strncat.  Don't worry if you don't
	understand the issue, don't worry if you heard someone
	say there's an obscure circumstance under which they
	might be useful, just don't ever use them; pretend they
	don't exist.

Though perhaps not strictly true, this is good advice, because it
will never lead the average programmer astray.

strncpy is not a "fine function", because nobody is using
(or should be using) fixed-width string buffers any more.
(See, I can be opinionated, too! :-) )

But we don't need to argue about this.  I said "strncpy and
strncat are the new gets" to concede a point, to agree that
discouraging the use of formerly-acceptable interfaces --
a point that I thought you, and certainly that various people,
were trying to make -- might be reasonable, even though it's one
I often find myself disagreeing with.  But that's an opinion I
decided to leave out of my previous message, and I'm not going to
go down that road here, either.

Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar]

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

Hi Steve,

> Date: 2026-08-02 09:45:17-0400
> From: Steve Summit <scs@eskimo.com>
>
> Alejandro wrote:
> >> Certainly, today, strncpy and strncat are the new gets.
> >
> > This is deeply incorrect.
> 
> That was a side point, but to clarify what I meant:
> 
> Once upon a time (and still today), it's a reasonable thing to say:
> 
> 	Never use gets.  Don't worry if you don't understand the
> 	issue, don't worry if you heard someone say there's an
> 	obscure circumstance under which it might be useful,
> 	just don't ever use it; pretend it doesn't exist.
> 
> Today I think it's equally reasonable to say:
> 
> 	Never use strncpy and strncat.  Don't worry if you don't
> 	understand the issue, don't worry if you heard someone
> 	say there's an obscure circumstance under which they
> 	might be useful, just don't ever use them; pretend they
> 	don't exist.

This is not equally reasonable.  First of all, because there really is
an obscure circumstance under which, not only they are useful, but
actuall they are the best tool for the job.  If you tell users to never
ever use them, you're treating users as childs uncapable of
understanding the facts.  In fact, the documentation should instead
document the facts in a way that programmers can understand them and use
them appropriately.

Secondly, because this somehow attributes the danger to specific
functions, but the danger is in misusing functions.  For example, N2349,
which standardized memccpy(3), was following this premise: strncpy(3)
and strncat(3) are bad, so let's just find anything else; as long as
it's not one of those two functions, it should be fine.  But because
the underlying problem is not --and never has been-- the tools, but the
humans that misuse them, we have the irony that memccpy(3) is as
dangerous as strncpy(3), and even the paper that proposed it for
standardization invokes UB in the example code that is supposed to show
how it can be used for string copying.

> Though perhaps not strictly true, this is good advice, because it
> will never lead the average programmer astray.

No, it's not good advice either.  memccpy(3) and N2349 is a
counter-example of how even an expert programmer (Martin Sebor) will
still be led astray.

> strncpy is not a "fine function", because nobody is using
> (or should be using) fixed-width string buffers any more.
> (See, I can be opinionated, too! :-) )

I do use it in new code still today in shadow-utils.  I've heard tar(1)
also needs that, and a few other places.  Admittedly, that's orders of
magnitude less than strings.

> But we don't need to argue about this.  I said "strncpy and
> strncat are the new gets" to concede a point, to agree that
> discouraging the use of formerly-acceptable interfaces --
> a point that I thought you, and certainly that various people,
> were trying to make --

Not exactly; my point is that education must be used to teach users how
to correctly use interfaces.  I consider all these interfaces perfectly
acceptable.


Cheers,
Alex

> might be reasonable, even though it's one
> I often find myself disagreeing with.  But that's an opinion I
> decided to leave out of my previous message, and I'm not going to
> go down that road here, either.

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

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