on the irresponsibility of pursuing C language reform

[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.

As for strncat, its API is a recipe for confusion and almost nobody 
remembers how it works. It is a poor design, plain and simple. Although 
strncpy may have a use or two for obsolete non-string data structures 
that 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. In contrast, 
the glibc manual has reasonably decent warnings to users about how bad 
strncat is (strncpy/strlcpy/etc. too).

To improve the man pages it should be waayyy higher priority to fix 
their poor discussion of these truncation functions than to worry about 
whether the man page mentions <string.h> or some other header.