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

Alejandro Colomar <[email protected]> Sat, 1 Aug 2026 00:33:12 +0200

Newsgroups	gmane.linux.man,gmane.comp.lib.gnulib.bugs,gmane.comp.lib.glibc.alpha
Message-ID	<am0h6_aBF2iEvpu5@devuan>

Hi Joseph,

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

Those are the most misused, indeed.

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

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

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

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

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

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

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

We disagree.


Cheers,
Alex

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

signature.asc (application/pgp-signature, 833 B)