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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 3 Dec 2015 13:08:49 -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>
On Thu, Dec 3, 2015 at 12:56 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 12/03/2015 09:36 AM, Zack Weinberg wrote:
>>
>> I would not at all be surprised to find code deliberately calling
>> strlcpy with destination size zero in order to learn how big the
>> destination buffer needed to be.
>
> 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;
}
If you're inclined to write this function using strlcpy in the first
place, using it both to compute the buffer size and to do the copy is
natural.
> Also, would you be surprised by a call strlcpy (NULL, SRC, 0) instead of the
> more-obvious strlen (SRC)?
I would actively expect strlcpy (0, SRC, 0) to be used; indeed, I
would expect it to be *more* common than passing a non-null buffer
with a zero size.
> Florian's proposed wording (like my proposal)
> would prohibit such a call. Even though strlcpy (NULL, SRC, 0) works just
> fine on BSD and the OpenBSD and FreeBSD man pages don't prohibit it,
> surely glibc doesn't need to support this usage
If we're going to have these functions at all, they need to work
_exactly_ as they do on *BSD.
Also, accepting a null destination buffer along with a zero
destination size is consistent with snprintf.
zw