This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcat [BZ#178]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 24 Nov 2015 10:52:46 -0800
- Subject: Re: [PATCH] Implement strlcat [BZ#178]
- Authentication-results: sourceware.org; auth=none
- References: <56547472 dot 3010302 at redhat dot com>
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.