Re: [PATCH] Implement strlcat [BZ#178]

[Paul Eggert <eggert at cs dot ucla dot edu>]

As it makes little sense to have strlcpy without strlcat and I can't 
imagine installing one patch without the other, the two patches should 
be combined for review.

I agree with nearly everything Joseph wrote in his long message about 
the policy for glibc APIs. However, it doesn't follow that glibc should 
have strlcpy+strlcat. Although our policy should be that when BSD has 
good ideas we should use the corresponding APIs, we're not obliged to 
implement BSD's bad APIs. This is not a question of ideology -- it has 
nothing to do with the GNU Manifesto, for example -- it's just that bad 
APIs are bad APIs.

Assuming I can't stop the steamroller and strlcpy/strlcat will be 
installed despite my objections, I have two further comments.

First, the proposed change to the manual still suffers from the problems 
I mentioned earlier, and the strlcpy patch makes these problems worse. I 
would like to help fix this by condensing my scattered 
documentation-related comments into a proposed patch. Unfortunately the 
currently-proposed documentation changes for strlcpy seems to be 
scattered as well, as the patch in 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00355.html> seems to be 
superseded by more-recent changes noted in passing in later emails. 
Florian, could you please prepare a combined up-to-date strlcpy+strlcat 
patch to manual/string.texi for me to comment on? (If you combine the 
two patches as I suggested in this email's first paragraph, the combined 
string.texi patch would simply be part of that. Or if the 
strlcpy+strlcat are in a public git branch somewhere, please just point 
me at that.)

Second, strlcpy and strlcat should both be marked __wur.  This would 
remove a significant part of my objection to the proposed change, which 
is that these poorly-designed APIs encourage silent-truncation bugs.