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). Any reasonable change there would involve a new header, say <strnpad.h> for strncpy and strncat, rather than resurrecting a very old one. > 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. Changing the header memcpy is in is just as ridiculous at this point as the proposal there once was to obsolesce NULL. > 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 more 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. -- Joseph S. Myers [email protected]
