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: Mon, 7 Dec 2015 08:57:50 -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> <5660C545 dot 1090805 at cs dot ucla dot edu> <5661A123 dot 9050408 at panix dot com> <5661BD09 dot 5020408 at cs dot ucla dot edu>
On 12/04/2015 11:19 AM, Paul Eggert wrote:
> On 12/04/2015 06:20 AM, Zack Weinberg wrote:
>> I really do not see this as a weird corner case.
>
> It's a weird corner case because it violates the natural programmer
> expectation that strlcpy and strlcat produce null-terminated strings.
When there is no space to write a nul-terminated string into, there is
no such expectation. And "no space" is what bufsiz=0 *means*.
Moreover, there is another - and, I'd argue, stronger - natural
programmer expectation, which is that when a buffer size is zero, the
associated pointer(s) will not be dereferenced. I know that the C
standard does not require this for e.g. memcpy, but I very strongly
suspect that if you polled a random sample of experienced C programmers
they would react to that basically the same way they react to being told
that signed integer overflow is undefined, i.e. "that's stupid and the
standard should be changed."
> There's no way that a typical C programmer will call strlcat and think,
> "OK, now I have to worry about whether the result is null-terminated".
> It's a misuse of programmer time to even raise the possibility. The
> whole *point* of these poorly-designed functions is to generate
> null-terminated strings come hell or high water, regardless of how long
> the inputs are.
I could be convinced that the OpenBSD semantics are wrong, but only if
you (being the person demanding a change from those semantics) find a
piece of existing code that can *accidentally* call either strlcpy or
strlcat with a zero buffer-size argument. That means code that was
intended to always call one of these functions with a nonzero
buffer-size argument, but, depending on input and other external
factors, might in practice call it with a zero buffer-size argument.
Failing such an exhibition, I will continue to insist on _exactly_
matching the OpenBSD semantics or else not having these functions at all.
zw