[PATCH] Implement strlcat [BZ#178]

[Paul Eggert]

On 12/11/2015 04:09 AM, Florian Weimer wrote:
> This implementation comes with documentation and it says

My comments were about the OpenBSD implementation, not the 
documentation.  If implementation compatibility is required (which I 
think was Zack's point), we need to fix incompatibilities with the 
OpenBSD implementation, even if these incompatibilities aren't documented.

Conversely, if implementation compatibility is not required, then we 
needn't reproduce OpenBSD's behavior exactly on weird corner cases that 
come up only with buggy applications. NetBSD does this to some extent, 
and if we're going to implement strlcpy+strlcat at all, we could do so 
as well.  So, for example, it would be fine if _FORTIFY_SOURCE caused 
strlcpy to report an error when given overlapping arguments, even though 
OpenBSD's strlcpy implementation has well-defined behavior in that 
situation.

Either approach would be better than a randomish glibc implementation, 
partially compatible with OpenBSD's weird quirks and partially not, with 
no principle for when we're compatible and when not.

> “If the src and dst strings overlap, the behavior is undefined.”
>
> <http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/string/strlcpy.3>

If the goal is to implement this spec (and implementation compatibility 
is not required), then this quote says the destination is a string, 
which means the destination buffer is null-terminated for strlcat, and 
also means SIZE is nonzero for both strlcpy and strlcat. And that is 
what my proposed strlcpy+strlcat doc patch says, albeit more clearly. Of 
course other parts of the OpenBSD spec talk about what to do when SIZE 
is zero or the strlcat destination is not a string, but what can I say? 
The OpenBSD spec is confused and contradicts itself, and this gives us 
wiggle room to interpret it reasonably for these weird corner cases.

Thanks, by the way, for being so patient with all this. This API is such 
a pain.