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

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

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

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

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

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

[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: 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: [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: 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: 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: [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: [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: [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 (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: 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>

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

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

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

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