Hi Branden, > Date: 2026-07-31 18:32:53-0500 > From: "G. Branden Robinson" > [...] > > Okay, well, 's out due to the above, and collides with > old, non-standard Borland and Watcom compilers (which live on still in > environments like FreeDOS[1]). > > So how about or for the standard mem* > functions? As I said, I think it's the other way around. is great, because there's no public record of it being obsolescent. It has only been _implicitly_ obsolescent, but the fact that it has remained without much attention make it a good candidate. Just as much as it was done with memccpy(3) in C23, except that memccpy(3) was brought back for bogus reasons (it's as bad as strncpy(3) for the purpose it was standardized). is already available in all systems that matter, so programs can start using it today, as opposed to , which could only be used relied upon around 2036 --for the early adopters--. If we didn't have the old header, I'd certainly prefer , but for these reasons, seems the way to go. > > Any reasonable change there would involve a new header, say > > 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. I strongly disagree. And a cordon sanitaire wouldn't help. That's the approach that n2349 took, and it was bogus. It's not a matter of saying "these two functions are bad". It's a matter of learning what each function is good for. And all of mem*() and strn*() are good for memory handling and nonstring handling (which can be considered a specific case of memory handling). Thus, all of them belong in . A cordon sanitaire will continue to ignore the fact that the problem is not in the functions themselves, but in how users think of these functions. I expect in 10 years from now, if we don't do anything, people will notice the same problems in memccpy(3) that we now attribute to strncpy(3). Just look at all the garbage that people have written with memccpy(3) after it was standardized in C23. A Debian code search will suffice to show the brain damage. Or you can just look at n2349, the paper that proposed it for its standardization, which already has UB in the examples of how it can be used for copying strings. It's all just too ironic. Let's make it easy to understand these functions, and avoid blaming any functions for what really is our lack of understanding. > > > The solution of moving both mem*() and strn*() to and > > > leaving just str*() in is a consistent one, because > > > then remains strictly for string APIs, and 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 , and then > > > leave mem*() in , of course. > > > > > > Similarly, it wouldn't be reasonable to [move] strncpy/cat() to > > > and leave the rest of strn*() and all of mem*() in > > > . > > > > 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 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. +1 > 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). +1 > WG14 has been moving away from that notion for decades now. A recent > example is . 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. For the reasons above, is better. About the third header, I originally thought that, and in alx-0097 I wrote about adding a header. However, the more I think about it, the more I think these are just fine in . The Linux kernel for example, renamed strncpy(3) to strtomem_pad() --and as discussed within WG14, the _pad in that name is redundant, so it could perfectly have been called strtomem()--. This shows that these functions are not as unrelated to as their current names suggest. This, combined with the fact that they are already available through , makes me think that we should just put them in , which would lead people to think about a binary distinction between for string-only, and for memory stuff that doesn't handle strings. Have a lovely day! Alex > > Regards, > Branden > > [1] https://www.freedos.org/books/cprogramming/part8/ --