[PATCH] Implement strlcat [BZ#178]

[Florian Weimer]

On 12/07/2015 10:05 PM, Paul Eggert wrote:
> On 12/07/2015 05:57 AM, Zack Weinberg wrote:
>> I will continue to insist on_exactly_
>> matching the OpenBSD semantics or else not having these functions at all.
> 
> (I agree, as I think glibc shouldn't have these functions at all. That
> being said...)
> 
> If I understand the above comment correctly, you have at least three
> reasons to object to the proposed strlcpy+strlcat implementation.
> 
> First, it rejects null pointer arguments.

Yes, I'm going to fix that.

> Second, when arguments overlap it doesn't necessarily have the same
> behavior as the OpenBSD implementation. For example, the OpenBSD strlcpy
> implementation always has well-defined behavior when source and
> destination overlap, but the proposed implementation does not.

The OpenBSD implementation is defined to be undefined with overlapping
inputs, too.

> Third, the OpenBSD implementation declares strlcpy and strlcat to have
> __attribute__ ((__bounded__ ...)), an OpenBSD extension that generates
> warnings when compiling with gcc -Wbounded (an OpenBSD GCC option that
> is on by default). The proposed implementation doesn't do that so it by
> default does not diagnose bugs that the OpenBSD implementation does
> diagnose.

Doesn't the _FORTIFY_SOURCE wrapper do something similar?

>> When there is no space to write a nul-terminated string into, there is
>> no such expectation.
> 
> Sometimes there *is* space; that is, the destination size is nonzero,
> but the proposed strlcat *still* doesn't store a terminating null. 
> Doesn't this give you qualms?  It does me.

Yes, it's annoying, particularly since it is inconsistent with strlcpy
and snprintf.  I'm not sure if we can change that, I'll ask.

Florian