Hi Paul, > Date: 2026-08-02 14:28:33-0500 > From: Paul Eggert > > On 8/2/26 09:11, Alejandro Colomar wrote: > > 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. > > GNU tar proper has not used strncpy since 2018. It generally uses memcpy in > the places it formerly used strncpy. Tar's 2018 change worked because the > destinations were already zeroed out, so strncpy's zero-fill semantics were > unnecessary and indeed a bit slower. Ok; thanks! In shadow-utils we still need it, though. > As for strncat, its API is a recipe for confusion The semantics are okay. strncat(3) is for example useful for implementing strndupa(3), which is quite useful (just like strndup(3)) if you use substrings or other fixed-width arrays. #define strndupa(s, n) strncat(strcpy(alloca(n + 1), ""), s, n) It's weird that there's no cpy version of it, though, but this is solved with the usual strcpy(p,"") as first argument. And the name is certainly bad in context, although an appropriate name would be much more verbose: strcatfrommem(). Maybe we can live with the name strncat(3). > and almost nobody > remembers how it works. This is true, and in part, it's because of bad teaching. The fact that GCC's diagnostics recommend bogus usage don't help. I think having it in could help understand it and remember it. > It is a poor design, plain and simple. There's a need for taking a nonstring (i.e., a fixed-width null-padded buffer, or a substring) and append it to a string. strncat(3) is good for that use case. > Although > strncpy may have a use or two for obsolete non-string data structures that Substrings are still necessary. If you want to copy the leading part of a string until a given length, and append it to an existing string, you need strncat(3). I guess this doesn't violate any guidelines. For this use, in some sense, it's similar to memccpy(3). You don't use it all the time, but when you need it, it's useful. > violate GNU coding guidelines that have been in place since the 1980s, > strncat has no such redeeming virtues. The current man page for strncat does > readers a misservice by not saying so clearly. I disagree that strncat(3) is dead, and will not document it as such. Moving it to would signal that it's something less appropriate for usual code using strings. > In contrast, the glibc manual > has reasonably decent warnings to users about how bad strncat is > (strncpy/strlcpy/etc. too). Let's review that. 5.5 Concatenating Strings ... Programmers using the strcat or wcscat functions (or the strlcat, strncat and wcsncat functions defined in a later section, for that matter) can easily be recognized as lazy and reckless. Lazy can be a virtue, IMO. I wouldn't call them reckless. If they know the prefix string is controlled and small, using the cat functions can be wise: you don't waste much performance, and instead get a simple program. Plan9's strecpy(2) is certainly faster, and doesn't add much complexity, but it still adds a little bit of complexity, so it can sometimes make sense to keep the source simple, at the expense of a few cycles. In almost all situations the lengths of the participating strings are known (it better should be since how can one otherwise ensure the allocated size of the buffer is sufficient?) You may know an upper bound without caring about the exact value. Yes, most of the time you know it, but I wouldn't dismiss those times where you don't know (or, for simplicity, you don't want to know). Or at least, one could know them if one keeps track of the results of the various function calls. Indeed, but simplicity might call for not doing this. The compiler can do it for us. But then it is very inefficient to use strcat/wcscat. The compiler can do it for us. Correct simple code is better than fast code; and correct code can be optimized by compilers. Since, as you said, the length is easy to find if you keep track of the return values --and the compiler can keep track of them--, then it's a case for improving optimizers. A lot of time is wasted finding the end of the destination string so that the actual copying can start. ... Whenever a programmer feels the need to use strcat she or he should think twice and look through the program to see whether the code cannot be rewritten to take advantage of already calculated results. As said, give me a better compiler, and I'll give you a faster program. The related functions strlcat, strncat, wcscat and wcsncat are almost always unnecessary, too. Again: it is almost always unnecessary to use functions like strcat. Again, I don't agree. --- 5.6 Truncating Strings while Copying ... Function: char * strncat (char *restrict to, const char *restrict from, size_t size) strncat(3) does *not* truncate its input. It copies exactly as many bytes as the source nonstring contains (identified by the pointer and size), unless the source nonstring is shorter, of course, in which case, it's not truncation. It doesn't belong in this section. This is part of the reason why it's misunderstood and misremembered by people: nobody explained it correctly to them. ... This function is like strcat except that not more than size bytes from from are appended to the end of to, and from need not be null-terminated. This is pretty much saying that a cat is similar to a fish, except that the cat doesn't live in the sea, and it is a mammal. A single null byte is also always appended to to, so the total allocated size of to must be at least size + 1 bytes longer than its initial length. This is good advice, but not precise wording. If the source nonstring is shorter than its reported size, then the total allocated size need not be so large. Of course, it's good advice that the size is always enough for the worst case, but the wording doesn't seem to be clear that this is only advice, and not a requirement. The strncat function could be implemented like this: char * strncat (char *to, const char *from, size_t size) { size_t len = strlen (to); memcpy (to + len, from, strnlen (from, size)); to[len + strnlen (from, size)] = '\0'; return to; } This one might be faster and shorter (thanks to Mark for teaching me this): { if (memccpy(to + strlen(to), from, '\0', size) == NULL) strcpy(&to[strlen(to) + size], ""); return to; } ... As a companion to strncpy, strncat was designed for now-rarely-used arrays consisting of non-null bytes followed by zero or more null bytes. But it also works for substrings. If you want to copy a prefix from a string into a new string, strncat(3) --or the dup versions, strndup[a](3)-- help. However, As noted below, this function is generally a poor choice for processing strings. Yes, it's a poor choice for handling strings. By moving it to , we signal that it's not for handling strings. Also, this function has significant performance issues. See Concatenating Strings. Those are a problem of the optimizer, not of the programmer. ... Because these functions can abruptly truncate strings or wide strings, they are generally poor choices for processing them. When copying or concatening multibyte strings, they can truncate within a multibyte character so that the result is not a valid multibyte string. When combining or concatenating multibyte or wide strings, they may truncate the output after a combining character, resulting in a corrupted grapheme. They can cause bugs even when processing single-byte strings: for example, when calculating an ASCII-only user name, a truncated name can identify the wrong user. strncat(3) does not truncate its input, and thus this doesn't tell much about it. It rather compounds on the historic misunderstanding of the function. > To improve the man pages it should be waayyy higher priority We don't need to prioritize. I have plenty of time to address both issues. While I wrote string_copying(7) for clarifying what strncat(3) is and is not (alongside all the other string-copying functions). I need to revise that page, since I've learnt a lot since I wrote it. I also need to add at least some paragraph in CAVEATS in strncat(3), since readers might not find the other page at all --even if it's in SEE ALSO--. I'll address all of these. > to fix their > poor discussion of these truncation functions That's a wrong categorization of this function. strncat(3) has nothing to do with truncation (as said above). > than to worry about whether > the man page mentions or some other header. Have a lovely night! Alex --