[PATCH 1/2] man/man3/{mem, strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)
Christopher Bazley
chris.bazley.wg14@gmail.com
Sat Aug 1 14:26:05 GMT 2026
Hi,
On Sat, Aug 1, 2026 at 12:32 AM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> WG14 has been moving away from that notion for decades now. A recent
> example is <stdbit.h>. Why not continue in that laudable direction?
>
> I think
>
> stdmem.h
> string.h
> stdstrn.h
>
> would sharply separate concerns and promote clearer reasoning among
> application developers.
I have been reluctant to stick my oar into this argument, but the
proposal above is the best I have seen so far. The trouble with
Alex's assertion that the strn... functions are not string functions
and therefore must be memory functions is that it strikes me as a
false dichotomy. I understand why he makes that claim, and I
understand the damage the confusion has caused, but I do not find it
entirely plausible given that strncat appends to a string and strncpy
can consume one. I also understand the deep attraction of righting
past wrongs, but it seems to me that, in this instance, the past was
not so satisfactory either.
I am skeptical that many users will include header files that did not
exist before C2Y, but it may be worth trying. I do not think the
proposal to restore <memory.h> would be much better: it does not exist
on many platforms. If we are going to introduce a new separation, let
us make it a good one.
Christopher
More information about the Libc-alpha
mailing list