At 2026-07-31T23:11:56+0000, Joseph Myers wrote: > On Sat, 1 Aug 2026, Alejandro Colomar wrote: > > > In other words, they were in that header for 6 years, and it's > > > been implicitly obsolescent by virtue of the standard choice for > > > the 37 years since then. > > Yes. And I'm trying to revert the implicit obsolescence. > > Obsolescence isn't a one-way process. Sometimes, evidence shows up, > > and the obsolete feature must come back for $reasons. > > When it's been obsolescent for 37 years, bringing back a header with > the same name is just going to confuse people with 37 years of past > information saying it's obsolescent (normally if one source says "use > X" and another says "X is obsolescent", you can reliably assume that > "X is obsolescent" is the more recent information, even without 37 > years of history involved).
Okay, well, <memory.h>'s out due to the above, and <mem.h> collides with
old, non-standard Borland and Watcom compilers (which live on still in
environments like FreeDOS[1]).
So how about <stdmem.h> or <stdmemory.h> for the standard mem*
functions?
> Any reasonable change there would involve a new header, say
> <strnpad.h> for strncpy and strncat, rather than resurrecting a very
> old one.
I agree with that. As my previous email noted, I think C programmers
apply the mem* functions differently than they do str{n,}*. I think
it's a good idea to erect a cordon sanitaire around the ever-troublesome
latter functions.
> > The solution of moving both mem*() and strn*() to <memory.h> and
> > leaving just str*() in <string.h> is a consistent one, because
> > <string.h> then remains strictly for string APIs, and <memory.h> is
> > for the rest of byte handling.
>
> It's inconsistent with how people have understood C ever since it was
> standardized.
This claim is a bit hand-wavy. C has spent its entire lifetime being
notoriously poorly understood. But especially in early days, the
compiler would spit out something anyway. Hackers confused the
production of a linked object file with understanding the language.
C has single-handedly elevated "undefined behavior" into a field of
academic study.
> > It wouldn't be reasonable to move strn*() to <memory.h>, and then
> > leave mem*() in <string.h>, of course.
> >
> > Similarly, it wouldn't be reasonable to [move] strncpy/cat() to
> > <memory.h> and leave the rest of strn*() and all of mem*() in
> > <string.h>.
>
> On the contrary, it's only the functions for null-padded fixed-width
> buffers that are niche functions causing confusion, compared to all
> the rest of the functions in <string.h> for which it's a very
> well-established and well-understood location. Some others like
> memccpy are *obscure*, but not confusing in the same way.
I agree with you here, but the base+bounds nature of the mem* functions
versus the null-terminated nature of the str[^n]* functions, warrants
separation.
37 years ago the C Committee seemed to feel it needed to economize on
standard header file names, so many unrelated interfaces got piled
together into .h files that consequently lacked coherence (in the
Yourdon/Constantine sense).
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.
Regards,
Branden
[1] https://www.freedos.org/books/cprogramming/part8/
signature.asc
Description: PGP signature
