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

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

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.

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

index 706f8152f58c..a6bc4e8a3e0b 100644
@@ -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

index 0a493ff4029d..f3ee95c00406 100644
@@ -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

index 9cecb282ba4f..467f24cb39a7 100644
@@ -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

index f8f049bf5c4c..7083dc3f7577 100644
@@ -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

index ee41da0ced7b..ad736949002c 100644
@@ -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 );

index 13fd8b7cea7b..d0f99e6d577d 100644
@@ -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 ,

index 99f152412142..65f6a67b9b35 100644
@@ -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

index 012e6326dd00..4598be5d7bc2 100644
@@ -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 ],

index 6e49defc5e4a..fe2841147f05 100644
@@ -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 );

index 91b3b476abf9..b69398a7762a 100644
@@ -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

index 5b1ec5595169..4d959fde9f83 100644
@@ -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 ()

index 65941ddf6524..a4100a0d0f02 100644
@@ -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

index 0a573e52d936..2909a0b7ea64 100644
@@ -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

index f3ab0611a323..c12cd3071dd9 100644
@@ -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 ()

index 63b12c83e9ec..412eec9f3491 100644
@@ -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

index dd39d54939d9..dc74e0fefbc3 100644
@@ -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

index 553a39a9ec7a..657fc8c7ae9c 100644
@@ -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

See previous commit.

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

index da87799a5e69..02c9897d8771 100644
@@ -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)

2.53.0

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

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>

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

Hi Joseph,

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

Have a lovely night!
Alex

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

Hi Joseph,

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

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.

sam

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

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.

sam

Hi Joseph,

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

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

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

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

Hi Sam,

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.

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.

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.

And it still does.

Have a lovely night!
Alex

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

Hi Joseph,

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>

Hi Sam,

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.

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/

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?

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

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

Hi Alex,

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

Hi Joseph,

Those are the most misused, indeed.

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

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

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

We disagree.

Cheers,
Alex

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

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

Hi Joseph,

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.

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.

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

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

Hi Joseph,

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

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.

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.

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

Hi Branden,

Indeed.

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.

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

Thanks for the support! :)

Have a lovely night!
Alex

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

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

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?

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.

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.

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/

Hi Joseph,

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.

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.

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.

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

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>

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

Hi Collin,

Or that it has been touched in 2026. :)

Cheers,
Alex

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

Hi Joseph,

I agree that there is a _potential_ moral hazard here.

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

Hi Collin,

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

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

Hi Branden,

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

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

Hi Sam,

[...]

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>

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.

---

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

index ee41da0ced7b..ad736949002c 100644
@@ -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 );

index 13fd8b7cea7b..d0f99e6d577d 100644
@@ -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 ,

index 012e6326dd00..4598be5d7bc2 100644
@@ -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 ],

index 6e49defc5e4a..fe2841147f05 100644
@@ -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 );

index 63b12c83e9ec..412eec9f3491 100644
@@ -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

Hi Sam,

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/[email protected]/>
<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>

Branden wrote

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

Hi Branden,

[...]

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.

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.

+1

+1

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

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

Hi,

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

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.

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.

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

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.

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?

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.

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.

sam

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

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

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.

Hi Branden,

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.

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

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.

Thanks for your thoughtful email. I found it helpful!

sam

Hi Sam,

[...]

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 <[email protected]>
	>
	> > Date: Thu, 30 Jul 2026 10:58:26 -0700
	> > From: Mark Harris <[email protected]>
	> >
	> > 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.

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.

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

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

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.

Thanks!

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'm not aware of anything that has not me in CC; sorry.

[...]

Thanks!

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]

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.

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>

Hi Chris,

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

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

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

Have a lovely day!
Alex

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

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

OK.

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

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

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

???

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.

See above.

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

What would real consensus against look like?

Hi Sam,

[...]

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'm not a random one-time reporter.

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

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

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.

[...]

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>

Hi Doug,

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

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

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

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

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

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

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

If it is, what is to be done?

Regards,
Branden

Hi Sam & Alex,

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

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

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

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

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

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

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

Regards,
Branden

Hi Branden, Doug,

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

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

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

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

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

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

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

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

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

Indeed.

And indeed.

And indeed.

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

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

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

I am certain that the solution exists.

Have a lovely night!
Alex

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

Hi Branden,

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

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

Here's the history of that file:

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

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

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

Cheers,
Alex

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

[...]

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

Cheers,
Alex

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

Hi Alex,

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

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

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

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

Regards,
Branden

Hi Branden,

:)

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

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

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

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

Yup.

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

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

Cheers,
Alex

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

Hi Alex,

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

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

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

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

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

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

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

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

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

Your first line of defense is your own ethical conscience.

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

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

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

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

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

Regards,
Branden

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

Hi Branden,

:)

Indeed.

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

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

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

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

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

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

Yup.

Yup.

Yup.

Yup.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
Alex

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

Hi Alejandro,

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

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

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

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

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

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

Thanks.

Bruno

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

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

Cheers,
Alex

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

Hi Bruno!

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

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

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

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

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

Sure! Thanks!

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

Thanks for the feedback!

Have a lovely night!
Alex

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

Hi Keith,

Thanks!

Fully agreed.

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

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

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

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

	--- HEAD^:man/man3/strdupa.3
	+++ HEAD:man/man3/strdupa.3
	@@ -11,6 +11,10 @@ SYNOPSIS
	      #include <string.h>
	 
	      char *strdupa(const char *s);
	+
	+     #define _GNU_SOURCE  /* See feature_test_macros(7) */
	+     #include <memory.h>
	+
	      char *strndupa(size_t n;
			    const char s[n], size_t n);
	 
	@@ -48,6 +52,9 @@ STANDARDS
	 HISTORY
	      GNU.
	 
	+NOTES
	+     The following header also provides strndupa(): <string.h>.
	+
	 SEE ALSO
	      alloca(3), strdup(3), strndup(3)

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

Have a lovely night!
Alex

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

Hi Bruno,

[...]

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

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

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

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

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

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

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

Cheers,
Alex

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

Hi Alejandro,

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

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

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

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

Bruno

Hi Keith,

[...]

[...]

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

	$ MANWIDTH=64 diffman-git HEAD
	--- HEAD^:man/man3head/memory.h.3
	+++ HEAD:man/man3head/memory.h.3
	@@ -10,6 +10,11 @@ SYNOPSIS
	      #include <memory.h>

DESCRIPTION
+ These functions are also provided in <string.h>, as speci‐
+ fied by ISO C. This is a historic accident maintained for
+ compatibility reasons. Don’t let that fool you; these
+ functions don’t necessarily operate on strings.
+
Write
bzero(3)
memset(3)
@@ -38,6 +43,19 @@ DESCRIPTION
memrchr(3)
memmem(3)

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

Cheers,
Alex

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

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

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

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

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

Collin

Hi Collin,

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

Have a lovely night!
Alex

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

Hi Paul,

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

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

Have a lovely night!
Alex

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

But this whole thread is about #includes, no?

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

Hi Alex,

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

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

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

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

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

I propose:

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

If you like the foregoing, consider it:

Regards,
Branden

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

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

But no head wears the crown.

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

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

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

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

So what remains for the motley crew left behind?

The man pages.

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

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

Why not?

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

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

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

Regards,
Branden

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

Hi Branden,

[pasted [1] here]

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

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

I'll think about it.

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

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

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

At the moment, I have it as:

	STANDARDS
	     BSD.

	HISTORY
	     SysV, 4.3BSD.

		...

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

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

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

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

I like part of this paragraph.

I'm not convinced.

I'll probably modify it and note it as

	Suggested-by: ...

Cheers,
Alex

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

Hi Branden,

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

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

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

Indeed.

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

Hmmm. Is there any copy of that?

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

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

Same happens here.

Cheers,
Alex

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

[...]

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

Cheers,
Alex

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

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

Collin

Hi Collin,

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

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

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

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

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

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

As Kant said:

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

https://existentialcomics.com/comic/293

Regards,
Branden

Hi Collin,

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

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

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

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

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

STANDARDS

	...

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

reallocarray() suffers the same issues in glibc.

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

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

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

HISTORY

	...

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

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

...

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

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

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

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

Have a lovely night!
Alex

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

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

In one of your original messages you mentioned the following:

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

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

Collin

Hi Collin,

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

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

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

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

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

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

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

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

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

Have a lovely day!
Alex

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

Hi Collin,

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

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

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

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

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

Cheers,
Alex

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

[...]

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

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

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

Cheers,
Alex

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

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

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

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

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

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

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

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

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

Steve Summit

Hi Steve,

[...]

This is deeply incorrect.

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

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

gets(3) is not that.

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

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

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

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

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

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

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

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

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

A simple implementation of strncpy() might be:

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

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

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

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

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

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

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

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

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

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

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

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

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

Have a lovely day!
Alex

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

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

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

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

Today I think it's equally reasonable to say:

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

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

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

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

Hi Steve,

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

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

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

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

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

Cheers,
Alex

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

GNU tar proper has not used strncpy since 2018. It generally uses memcpy in the places it formerly used strncpy. Tar's 2018 change worked because the destinations were already zeroed out, so strncpy's zero-fill semantics were unnecessary and indeed a bit slower.

As for strncat, its API is a recipe for confusion and almost nobody remembers how it works. It is a poor design, plain and simple. Although strncpy may have a use or two for obsolete non-string data structures that violate GNU coding guidelines that have been in place since the 1980s, strncat has no such redeeming virtues. The current man page for strncat does readers a misservice by not saying so clearly. In contrast, the glibc manual has reasonably decent warnings to users about how bad strncat is (strncpy/strlcpy/etc. too).

To improve the man pages it should be waayyy higher priority to fix their poor discussion of these truncation functions than to worry about whether the man page mentions <string.h> or some other header.

Hi Paul,

Ok; thanks! In shadow-utils we still need it, though.

The semantics are okay. strncat(3) is for example useful for implementing strndupa(3), which is quite useful (just like strndup(3)) if you use substrings or other fixed-width arrays.

	#define strndupa(s, n)  strncat(strcpy(alloca(n + 1), ""), s, n)

It's weird that there's no cpy version of it, though, but this is solved with the usual strcpy(p,"") as first argument.

And the name is certainly bad in context, although an appropriate name would be much more verbose: strcatfrommem(). Maybe we can live with the name strncat(3).

This is true, and in part, it's because of bad teaching. The fact that GCC's diagnostics recommend bogus usage don't help. I think having it in <memory.h> could help understand it and remember it.

There's a need for taking a nonstring (i.e., a fixed-width null-padded buffer, or a substring) and append it to a string. strncat(3) is good for that use case.

Substrings are still necessary. If you want to copy the leading part of a string until a given length, and append it to an existing string, you need strncat(3). I guess this doesn't violate any guidelines.

For this use, in some sense, it's similar to memccpy(3). You don't use it all the time, but when you need it, it's useful.

I disagree that strncat(3) is dead, and will not document it as such.

Moving it to <memory.h> would signal that it's something less appropriate for usual code using strings.

Let's review that.

5.5 Concatenating Strings

...

Programmers using the strcat or wcscat functions (or the strlcat, strncat and wcsncat functions
defined in a later section, for that matter)
can easily be recognized as lazy and reckless.

Lazy can be a virtue, IMO. I wouldn't call them reckless. If they know the prefix string is controlled and small, using the cat functions can be wise: you don't waste much performance, and instead get a simple program. Plan9's strecpy(2) is certainly faster, and doesn't add much complexity, but it still adds a little bit of complexity, so it can sometimes make sense to keep the source simple, at the expense of a few cycles.

In almost all situations the
lengths of the participating strings are known (it better should be
since how can one otherwise ensure
the allocated size of the buffer is sufficient?)

You may know an upper bound without caring about the exact value. Yes, most of the time you know it, but I wouldn't dismiss those times where you don't know (or, for simplicity, you don't want to know).

Or at least,
one could know them if one keeps track of the results of the various function calls.

Indeed, but simplicity might call for not doing this. The compiler can do it for us.

But then it is very inefficient to use strcat/wcscat.

The compiler can do it for us. Correct simple code is better than fast code; and correct code can be optimized by compilers. Since, as you said, the length is easy to find if you keep track of the return values --and the compiler can keep track of them--, then it's a case for improving optimizers.

A lot of time is wasted
finding the end of the destination string
so that the actual copying can start.

...

Whenever a programmer feels the need to use strcat she or he should think twice and look through the program to see whether the code cannot be rewritten
to take advantage of already calculated results.

As said, give me a better compiler, and I'll give you a faster program.

The related functions strlcat, strncat, wcscat and wcsncat are almost always unnecessary, too.
Again:
it is almost always unnecessary to use functions like strcat.

Again, I don't agree.

	---
	5.6 Truncating Strings while Copying

	...

	Function: char * strncat (char *restrict to, const char *restrict from, size_t size)

strncat(3) does *not* truncate its input. It copies exactly as many bytes as the source nonstring contains (identified by the pointer and size), unless the source nonstring is shorter, of course, in which case, it's not truncation. It doesn't belong in this section. This is part of the reason why it's misunderstood and misremembered by people: nobody explained it correctly to them.

...

This function is like strcat except that not more than size bytes from from are appended to the end of to, and from need not be null-terminated.

This is pretty much saying that a cat is similar to a fish, except that the cat doesn't live in the sea, and it is a mammal.

A single null byte is also always
appended to to, so the total allocated size of to must be at least size + 1 bytes longer than its initial length.

This is good advice, but not precise wording. If the source nonstring is shorter than its reported size, then the total allocated size need not be so large. Of course, it's good advice that the size is always enough for the worst case, but the wording doesn't seem to be clear that this is only advice, and not a requirement.

	    The strncat function could be implemented like this:

	    char *
	    strncat (char *to, const char *from, size_t size)
	    {
	      size_t len = strlen (to);
	      memcpy (to + len, from, strnlen (from, size));
	      to[len + strnlen (from, size)] = '\0';
	      return to;
	    }

This one might be faster and shorter (thanks to Mark for teaching me this):

{
if (memccpy(to + strlen(to), from, '\0', size) == NULL)

    strcpy(&to[strlen(to) + size], "");

return to;
}

...

As a companion to strncpy, strncat was designed for now-rarely-used arrays consisting of non-null bytes followed by zero or more null bytes.

But it also works for substrings. If you want to copy a prefix from a string into a new string, strncat(3) --or the dup versions, strndup[a](3)-- help.

However, As noted below, this function is generally a poor choice for processing strings.

Yes, it's a poor choice for handling strings. By moving it to <memory.h>, we signal that it's not for handling strings.

Also, this function has significant performance issues. See Concatenating Strings.

Those are a problem of the optimizer, not of the programmer.

...

Because these functions can abruptly truncate strings or wide strings, they are generally poor choices for processing them. When copying or concatening multibyte strings, they can truncate within a multibyte character so that the result is not a valid multibyte string. When combining or concatenating multibyte or wide strings, they may truncate the output after a combining character, resulting in a corrupted grapheme. They can cause bugs even when processing single-byte strings: for example, when calculating an ASCII-only user name, a truncated name can identify the wrong user.

strncat(3) does not truncate its input, and thus this doesn't tell much about it. It rather compounds on the historic misunderstanding of the function.

We don't need to prioritize. I have plenty of time to address both issues. While I wrote string_copying(7) for clarifying what strncat(3) is and is not (alongside all the other string-copying functions). I need to revise that page, since I've learnt a lot since I wrote it. I also need to add at least some paragraph in CAVEATS in strncat(3), since readers might not find the other page at all --even if it's in SEE ALSO--.

I'll address all of these.

That's a wrong categorization of this function. strncat(3) has nothing to do with truncation (as said above).

Have a lovely night!
Alex

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

Well, this was a period when glibc was driven by personal preferences of
one particular maintainer, so I don't think it is a good example in this discussion. What problem are you trying to fix anyway, what's wrong with using <string.h> for the APIs in question?

Maciej

Hi Maciej,

Programmers misunderstand these functions (some more than others), and think they are appropriate for handling strings in ways that they are inappropriate.

If <string.h> was described as providing functions that exclusively handle strings, then programmers that only need to handle strings would naturally self-limit to functions from this header file.

Those programmers that need more niche memory functions --maybe because they need to handle a substring, or maybe because they need to handle a utmp(5) fixed-width null-padded character array-- can resort to <memory.h>, but that comes with the implied warning that those functions are not the simple interfaces that <string.h> probides; they are
sharper: you can do more with them, but you need to be more careful.

Most programmers can live in the safe bubble of <string.h>: those functions always require a string as input, and always provide a string as output. Plain and simple. It's difficult to write bugs when using those.

That's the rationale.

Have a lovely night!
Alex

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

I do not follow.

C has no namespaces, let alone qualified imports.

The name of a header providing some function is thus inconsequential.

Indeed, these functions are provided by many headers outside of these two (by accident most often, but sometimes intentionally).

No programmer is able to safely use any C function until they read its documentation.

This goes doubly so for functions operating on bit soup, like mem* and str*.

Arsen Arsenović

That's true.

Then why not have one official big header file for the whole standard?

#include <stdlibc.h>

When you answer that to your own satisfaction, I suspect you'll have little trouble following Alex's argument.

...which doesn't mean you'll agree with it.

Regards,
Branden

Plan 9 did this but with "#include <libc.h>" and it seems to have worked fine.

I can't help but wonder of what happens in WG 14 rejects this controversial, as obvious by this thread, change. Will the man-pages changes be reverted? Or will we slowly watch them document personal preferences instead of existing standards? After seeing weekly threads about the prototype changes, I don't think it is an unreasonable concern.

Collin

Hi Branden,

Heh, curious thing: Plan9 did exactly this (actually, two headers). :)

	#include <u.h>
	#include <libc.h>

Not that I support that idea, of course.

Indeed. Thanks! You've replied in less words than I would have, and were more clear than I would have been.

Have a lovely night!
Alex

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

Hi Collin,

[...]

This patch set is quite independent of the standard. It documents a header file that has been provided since forever in glibc and most other POSIX-ish systems, so changes to the standard are unlikely to have any effects. I've clarified this extensively. If you want to discourage me from applying the change, you should rather bring up technical reasons.

This passive-aggressive message is not something that will have the desired effects you could possibly reach with technical arguments.

Have a lovely night, please!
Alex

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

BTW, as I showed in another subthread, strncpy(3) did contain opinionated comments well before I was involved. If you're really going to accuse me of that, better make sure you get the history right.

Cheers,
Alex

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

Oh, and while at it, please also read my review of glibc's own opinionated and bogus documentation about string truncation.

Cheers,
Alex

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

[CC trimmed]

Hi Branden,

[...]

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

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

	NAME
	     memory.h - memory operations

	LIBRARY
	     Standard C library (libc, -lc)

	SYNOPSIS
	     #include <memory.h>

	DESCRIPTION
	   Write
	     bzero(3)
	     memset(3)

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

	   Catenate
	     strncat(3)

	   Duplicate
	     strndup(3)
	     strndupa(3)

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

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

	STANDARDS
	     BSD.

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

	HISTORY
	     SVr1, 4.3BSD.

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

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

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

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

	SEE ALSO
	     string(3), string_copying(7)

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

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

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

A sample here:

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

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

	STANDARDS
	     C11, POSIX.1‐2008.

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

The commit message attributes the text to both of you.

commit 44d6d3bbace4c5a459efb181bcd264b93a655698
Author: Alejandro Colomar <[email protected]>
Date: 2026-08-02 01:20:46 +0200

man/man3head/memory.h.3: STANDARDS, HISTORY: Document some history about <string.h> and <memory.h>

This text is an adaptation of text suggested by Keith and Branden.

Have a lovely night!
Alex

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

<https://www.biblegateway.com/passage/?search=Matthew%207:3-5&version=NIV>

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

Hi Alex,

I don't think this rhetorical tactic is a sound one. You are implying that because Collin (and perhaps others) are not on record as having already consistently opposed editorializing in the glibc manual, or in the Linux man-pages prior to your stewardship, that they are hypocrites.

First, that's not necessarily true. Who's read every word of either work? Who had already done so 5, 10, or 20 years ago?

A charge of hypocrisy can only stick well if you can establish that your interlocutors _endorsed_ the editorializing contemporaneously when it was done by someone else, but are refusing to endorse yours.

But there are more fundamental reasons to conduct this struggle on different grounds, which are that (1) people get to change their minds; and (2) people get to raise defects even if they are old ones.

Thus, if you feel justified in "relitigating", in Joseph's term, the ANSI C Committee's decision in the late 1980s to scotch the memory.h header file, then Collin gets to "relitigate" past editorializing by (I guess?) Michael Kerrisk in the Linux man-pages, or by the glibc authors in their Texinfo manual.

Thus, here you have handed Collin an easy annulment of your point: he can simply say, "well I object to those, too".

Every generation of engineers bears a responsibility to remake the world anew. That which endures does so because its quality is re-tested and re-proved by successive cohorts of humans growing up and running straight at it with their freshly trained minds and novel phenomena of recent invention. When an artifact persists because it's protected from the bratty young philistines by older people who, as William F. Buckley put it, stand athwart history and yell "stop!", it fails to prove its continued utility: it stops being an engineered product and becomes an antiquarian one.

Regards,
Branden

That's a bad implementation of strndupa for several reasons. (Some reasons are: it evaluates n multiple times, it overallocates stack space when strnlen (s, n) < n, it obviously has undefined behavior when n == SIZE_MAX, and it less obviously has undefined behavior because it uses alloca as the argument of a function call.) Fixing its problems makes it obvious that strndupa should not be implemented via strncat; it's much saner to use memcpy. Which is why glibc does it that way.

This example is not only not a good argument *for* strncat: it is an argument *against* strncat. It's yet another example of how strncat almost invariably encourages bad code.

As for the glibc manual's wording in this area, I readily concede that the the wording should be toned down (calling programmers "lazy" is just counterproductive), but its technical aspects are pretty much on target. Although one might valiantly argue that strncat etc. are about substrings, that's not their original design, that's not what they're good at, and that's not what they're mostly used for. What they're designed for, and what they're good at, and what they're mostly used for is arbitrary truncation of strings and string-like data, something that goes against the GNU programming guidelines, and something that programmers should be warned against.

We've already wasted too much of our valuable time on this topic so I'll let you have the last word.

Hi Alex,

I want to start by saying, that I think your motivation is crystal clear to any objective observer. And you are perfectly right!

Has anybody denied that those functions don't operate on strings? They don't even know what is the '\0' byte so they don't care about it at all. They operate on the memory region and they do it unmercifully.

Alex, there isn't any kind of mercy in the environment we breath. This is a crucial point to realize.

Now, it doesn't really/really matters which is the right header. Of course it is a header that exposes those functions. It isn't of course <string.h> but again it doesn't really matters. It could be matter if [g]libc.so was splitted in myriads of libraries, and the programmer [-l]inked with the corresponded library. This is not the case here. As others have been said you could just include <[g]libc.h> and been done with that.

Now, while you are perfectly right in principle, what it matters is exactly what are you doing! Recording the CAVEATS, mentioning alternatives, exposing deficiencies, etc. In other words being honest with what you are doing. And you are and this is impressive and you deserve appreciation.

Man pages and without a second thought is the most valuable resource for any C programmer, you don't even want to think C programming without them! My opinion is that they are very well thought and constructed, with the usual wisdom of our ancestors, without bells and whistles and undoubtedly one of our precious jewels.

Alex:
They matter about the standards, please don't forget that. No matter if the standard is right or wrong, this is what we have. Libc'es and compilers are following them. That is not to say that we have to surrender and obey to them as the ultimate truth, when it clearly is not. We still have to give our best to fight for the evolution. But fighting for the header is a loosing battle.

Others:
And while we all love tersenes and compactness, I strongly believe that they are also an educational tool. There is still a room for this. In my opinion this is also a fair objective by Alex, so please encourage him, as it is for our own good also and we've to feel lucky we've him in this position. Someone is getting really serious with his role! And this is extraordinary in our current time.

But and to be a bit cruel here. Does it really matters? Are going to be new programmers? Who we'll taught?

At this point and generally speaking for our current environment and specifically about C.

The C programming language it was the cornerstone of our programming universe.

But, today we live in the kindgom of Rust!

Coreutils were written in Rust and i think ubuntu adopted them. A C compiler has been written in Rust. Bun is written in Rust. Claude writes Rust!

Given those facts, programmers will be just reviewers! But you are some of the best ever born programmers, and you should perfectly understand that:

How on earth a reviewer can understand the mistake, if she never codes? And especially Rust which is zillion of times more complicated than C?

So in absence of logic in our world, C has an incalculable important role to play in time (if of course we'll be blessed with time).

As a song with that same name says:
It takes an ocean of trust in the kingdom of rust...

So even if we paint a wall in the desert, and when we finish a car runs fast and sand destroys the fine painting, there is no other thing to do than to repaint the wall.

Given that we all have to ask by Alex, to continue with what he is doing, as what he is doing is doing it with respect, and today this is precious.

Have a good afternoon,

p.s., i'm rather uneducated. But I started learn C in my 52 and I wrote a libc. I believe that the standard should open some bits the horizons, and be more open to higher abstractions, e.g.,

A copy/read/write/rm/rename file/dir (a good part of coreutils functionality) can be part of the standard. C is about algorithms. If an algorithm works once in C, it will work forever. If the C community consentrates to write all the kind of algorithms with care and love) C will have a role. Otherwise we should be prepared for the inevitable.

The only reason I can imagine for not having One Big Header in 2026 is the same reason why I wouldn't make the change Alex is proposing:
because someone already chose to create many headers and changing it would mean shuffling lots of code around for no gain.

I imagine that, at some point, the amount of time that it would take to read and parse such a header would've been a problem also. Perhaps that inspired the fragmentation. Perhaps not.

I do not know, I didn't do the historiography.

I do know that splitting an extremely widely used header (291,660 matches on Debian codesearch) to replace it with one used far less widely (11,459 matches on that same codesearch, some of which mention portability concerns as the motivation for including memory.h, and I suspect most of which also have an include of string.h in the same file, but I did not verify this) only means that people include both, perhaps conditionally, while seeing no changes outside of the preamble of their source files.

Arsen Arsenović

Hi Paul,

That can be solved with a local variable. I didn't worry about it, because I don't pass n++ to this thing.

True; I agree that for glibc it makes sense to implement it with memcpy(3). However, for code that's not in a public library --and thus can afford to be wasteful--, and must implement strndupa(3) to workaround the fact that musl doesn't provide it, then I think the simplicity of the strncat(3)-using implementation is worth it.

That's also true of n==456789. Anything not trivially small is already UB with alloca(3).

Is this still an issue? I thought we were past that limitation, but I was actually concerned when I wrote that code.

The manual page does warn about this:

On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space re‐ served by alloca() would appear on the stack in the middle of the space for the function arguments.

But since it happens to work in all modern systems I've used, I thought this was probably a thing of the past. It would be good to be more specific about this. If you know which systems are affected, it'd be interesting if you could send a patch for the alloca(3) manual page.

Actually, I've just realized that the few uses of strndupa(3) that we had in shadow-utils disappeared when we removed the logoutd(8) program in the latest release; thus, we can get rid of our strndupa(3) implementation. We still use strndup(3), though.

We still have one direct use of strncat(3) which I've been wondering whether we can get rid of, but every alternative I try seems to be worse than strncat(3).

	/*
	 * is_my_tty -- determine if "tty" is the same TTY stdin is using
	 */
	static bool
	is_my_tty(const char tty[UTX_LINESIZE])
	{
		char  full_tty[STRLEN("/dev/") + UTX_LINESIZE + 1];
		char  my_tty[countof(full_tty)];

		stpcpy(full_tty, "");
		if (tty[0] != '/')
			strcpy (full_tty, "/dev/");
		strncat(full_tty, tty, UTX_LINESIZE);

		if (ttyname_ra(STDIN_FILENO, my_tty) != 0) {
			(void) puts (_("Unable to determine your tty name."));
			exit (EXIT_FAILURE);
		}

		return streq(full_tty, my_tty);
	}

If you think this could be improved with something else, it'd be interesting to hear some advice.

Thanks!

I'm not so sure about the correctness of this claim. I'd be interested in learning more about its design, if anyone here knows about it.

Here's what I can read in the V7 sources:

	alx@devuan:~/src/unix/unix/v7$ grep -rn 'strncat('
	usr/src/cmd/dumpdir.c:153:			strncat(prefix, dir.d_name, sizeof(dir.d_name));
	usr/src/cmd/login.c:107:	strncat(homedir, pwd->pw_dir, sizeof(homedir)-6);
	usr/src/libc/gen/strncat.c:8:strncat(s1, s2, n)
	usr/man/man3/string.3:9:.B char *strncat(s1, s2, n)

There are exactly two calls in V7.

The dumpdir.c call is a perfect example of copying a nonstring (a fixed-size null-padded character array, in this case) into a string *without* truncation.

The login.c call indeed seems to be a use for truncation.

These are two very different uses, and it'd be interesting which one came first, and why the other one was used later.

I agree. I don't think the current documentation does warn against that use correctly, though.

Have a lovely day!
Alex

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

Hi Branden,

He doesn't need to have read every word of the glibc manual, but this precise text he could have read it, because it was mentioned by Paul in this thread (different subthread) prior (19:28 UTC) to his message, and reviewed by me also prior (20:31 UTC) to his message (23:27 UTC).

	Date: Sun, 2 Aug 2026 14:28:33 -0500
	From: Paul Eggert <[email protected]>
	Message-ID: <[email protected]>

	Date: Sun, 2 Aug 2026 22:31:59 +0200
	From: Alejandro Colomar <[email protected]>
	Message-ID: <am-eAGL6OWqP9Yah@devuan>

	Date: Sun, 02 Aug 2026 16:27:21 -0700
	From: Collin Funk <[email protected]>
	Message-ID: <[email protected]>

Also relevant is the fact that he accused me of "slowly" documenting "personal preferences". His wording implies that it wasn't there before. Maybe I misunderstood, though. I'd be happy to rectify if I was wrong.

While he didn't need to know whether it was there before, it would be good to make some effort to learn whether that was the case, before making such a serious accusation.

In this specific case, again, the relevant text had been shown by me in this thread (different subthread), prior to (13:17 UTC) his message, and thus again he should have known.