This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcat [BZ#178]
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 24 Nov 2015 17:51:04 -0500
- Subject: Re: [PATCH] Implement strlcat [BZ#178]
- Authentication-results: sourceware.org; auth=none
- References: <56547472 dot 3010302 at redhat dot com> <5654B1FE dot 5020100 at cs dot ucla dot edu> <5654B796 dot 7070302 at redhat dot com>
On Tue, Nov 24, 2015 at 08:16:38PM +0100, Florian Weimer wrote:
> On 11/24/2015 07:52 PM, Paul Eggert wrote:
>
> > 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.
>
> I'm attaching the consolidated documentation patch.
>
> > 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.
>
> I disagree. We don't do that for snprintf, which is very similar, and
> we do not check most snprintf results in glibc.
I'm with Florian on this. __wur is only appropriate for functions
where there is no safe way to use them if you ignore the return value.
This is not the case for strlcpy/strlcat. Sometimes you don't care
about truncation at all. Even if you do need to know truncation
status, it's obtainable simply by calling strlen.
As a general principle I feel that __wur should not be used to impose
coding style but only to detect things that are genuinely unsafe. I
believe there are existing places in glibc where this principle is
violated, but that's a topic for another discussion.
Rich