This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcat [BZ#178]
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 7 Dec 2015 08:49: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> <5656E018 dot 5020608 at cs dot ucla dot edu> <565F211A dot 2030909 at redhat dot com> <56607CD1 dot 3050209 at cs dot ucla dot edu> <CAKCAbMgDMK9wjfNEJYW7e-cN9s5aVhun6V08OXrcOgYKRYF7_g at mail dot gmail dot com> <5660825E dot 9020901 at cs dot ucla dot edu> <CAKCAbMi2zSJRjS=ceg8UvTYY18UrCWysaOFX+OzvKZQfeR9+SA at mail dot gmail dot com> <5661D4F8 dot 5040100 at redhat dot com>
On 12/04/2015 01:01 PM, Florian Weimer wrote:
> On 12/03/2015 07:08 PM, Zack Weinberg wrote:
>
>>> Calling strlcpy (DST, SRC, 0) instead of the more-obvious strlen (SRC)?
>>> Really? That would be bizarre. I'd like to see an example.
>>
>> char *my_strdup(char *s)
>> {
>> size_t bufsiz = strlcpy(0, s, 0) + 1;
>> char *buf = malloc(bufsiz);
>> if (!buf) return 0;
>> strlcpy(buf, s, bufsiz);
>> return s;
>> }
>
> The implementation I posted does not actually support that because (like
> virtually all C standard functions), a null pointer is not allowed even
> if the buffer size is zero.
I think that's a showstopper bug in your implementation; as I've been
saying to Paul, the semantics should _exactly_ match *BSD (OpenBSD,
specifically) or we shouldn't have these functions at all. If I'm
reading the OpenBSD manpages correctly, this applies to both strlcpy and
strlcat.
> This is incompatible with the C++ standard library, but I did not have
> any luck so far with convincing people that this needs to be fixed in
> the C standard. The strlcpy/strlcat patch is not the place for this
> general discussion, I think.
FWIW I would support a general policy of "if a buffer size is specified
as zero, the associated pointer(s) are not dereferenced". But agree
that this is a separate discussion.
zw