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

[Zack Weinberg <zackw at panix dot com>]

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