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

Christopher Bazley <[email protected]> Sat, 1 Aug 2026 15:26:05 +0100
Newsgroups gmane.comp.lib.gnulib.bugs,gmane.linux.man,gmane.comp.lib.glibc.alpha
Message-ID <CAEHU8x9cXuViHVSQY7iR+LtdSwHy9_og3FsbCWGGDUkN6e+gMw@mail.gmail.com>
Hi,

On Sat, Aug 1, 2026 at 12:32=E2=80=AFAM G. Branden Robinson
<[email protected]> wrote:
> WG14 has been moving away from that notion for decades now.  A recent
> example is <stdbit.h>.  Why not continue in that laudable direction?
>
> I think
>
> stdmem.h
> string.h
> stdstrn.h
>
> would sharply separate concerns and promote clearer reasoning among
> application developers.

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

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

Christopher