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

[Paul Eggert <eggert at cs dot ucla dot edu>]

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. 
This is hardwired into what programmers expect, and is this expectation 
is documented by the FreeBSD man pages. And it is why the BSD man pages 
say "this should not happen" when talking about these weird corner cases.

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 accept that in this sense strlcpy+strlcat differ from snprintf but 
there's a good reason for that. With snprintf, one can't easily compute 
the needed length without calling snprintf, so there's a natural pattern 
of calling snprintf with a zero size, then allocating N+1 bytes, then 
calling snprintf again.  With strlcpy this pattern does not arise. 
First, anybody who's trying to allocating a buffer of proper size will 
not be calling strlcpy in the first place; they'll be calling plain 
strcpy or memcpy or whatever because the output buffer will be big 
enough once it's allocated. Second, the natural way to compute a string 
length is to call strlen, not to call strlcpy (NULL, SRC, 0) which is a 
weird corner case and does not work in NetBSD anyway.