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