Hi Steve, > Date: 2026-08-02 09:45:17-0400 > From: Steve Summit > > Alejandro wrote: > >> Certainly, today, strncpy and strncat are the new gets. > > > > This is deeply incorrect. > > That was a side point, but to clarify what I meant: > > Once upon a time (and still today), it's a reasonable thing to say: > > Never use gets. Don't worry if you don't understand the > issue, don't worry if you heard someone say there's an > obscure circumstance under which it might be useful, > just don't ever use it; pretend it doesn't exist. > > Today I think it's equally reasonable to say: > > Never use strncpy and strncat. Don't worry if you don't > understand the issue, don't worry if you heard someone > say there's an obscure circumstance under which they > might be useful, just don't ever use them; pretend they > don't exist. This is not equally reasonable. First of all, because there really is an obscure circumstance under which, not only they are useful, but actuall they are the best tool for the job. If you tell users to never ever use them, you're treating users as childs uncapable of understanding the facts. In fact, the documentation should instead document the facts in a way that programmers can understand them and use them appropriately. Secondly, because this somehow attributes the danger to specific functions, but the danger is in misusing functions. For example, N2349, which standardized memccpy(3), was following this premise: strncpy(3) and strncat(3) are bad, so let's just find anything else; as long as it's not one of those two functions, it should be fine. But because the underlying problem is not --and never has been-- the tools, but the humans that misuse them, we have the irony that memccpy(3) is as dangerous as strncpy(3), and even the paper that proposed it for standardization invokes UB in the example code that is supposed to show how it can be used for string copying. > Though perhaps not strictly true, this is good advice, because it > will never lead the average programmer astray. No, it's not good advice either. memccpy(3) and N2349 is a counter-example of how even an expert programmer (Martin Sebor) will still be led astray. > strncpy is not a "fine function", because nobody is using > (or should be using) fixed-width string buffers any more. > (See, I can be opinionated, too! :-) ) I do use it in new code still today in shadow-utils. I've heard tar(1) also needs that, and a few other places. Admittedly, that's orders of magnitude less than strings. > But we don't need to argue about this. I said "strncpy and > strncat are the new gets" to concede a point, to agree that > discouraging the use of formerly-acceptable interfaces -- > a point that I thought you, and certainly that various people, > were trying to make -- Not exactly; my point is that education must be used to teach users how to correctly use interfaces. I consider all these interfaces perfectly acceptable. Cheers, Alex > might be reasonable, even though it's one > I often find myself disagreeing with. But that's an opinion I > decided to leave out of my previous message, and I'm not going to > go down that road here, either. --