[PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>
Alejandro Colomar
alx@kernel.org
Fri Jul 31 22:33:12 GMT 2026
Hi Joseph,
> Date: 2026-07-31 22:16:14+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
>
> > That's 37 years. During these 37 years we have gathered a lot of
> > experience and data about this. And the conclusion is that it was
> > a huge mistake. Programmers have struggled to understand this, and
>
> No, there's no such conclusion. Two functions, strncpy and strncat, are
> with hindsight confusing (but it's the names and semantics rather than the
> header that are confusing).
Those are the most misused, indeed.
> I don't think there's any kind of community
> consensus at all that there's any problem with mem* being in <string.h>,
> or any functions other than those two.
But it's a consistent solution that keeps all existing functions (thus,
not a breaking change), and puts them in a header file that is
appropriate (and which has been their header since 1986).
> The committee writing C89 had to come up with a compromise between
> functions such as memcpy and strchr and functions such as bcopy and index.
> They chose to adopt memcpy and strchr,
This was a good choice. mem*() were more portable back then.
> and chose to put them in
> <string.h>,
This wasn't a good choice. They were already in <memory.h> in existing
systems.
> and there's no evidence since then to suggest a problem with
> either choice.
We disagree.
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260801/678fbed9/attachment-0001.sig>
More information about the Libc-alpha
mailing list