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

[Zack Weinberg <zackw at panix dot com>]

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