Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]

[Florian Weimer <fweimer at redhat dot com>]

On 01/05/2016 11:08 PM, Paul Eggert wrote:

> The original description also contains some contrary wording elsewhere
> "(as long as size is larger than 0)", but the point is that the spec has
> *always* been confusing and contradictory in this area. Really, the only
> safe way for an application to follow the original spec, is to avoid
> calling these functions with zero sizes.
> 
> Granted, the description of strlcpy has mutated and there are now
> versions floating around that talk about size-zero more consistently,
> but it is not at all clear that this was prompted by application needs
> or that applications depend on it or should depend on it. It looks more
> like a case of library implementers trying to clean up a messy spec
> without thinking things through carefully enough.

Hmm.  So maybe it is better to leave this undefined after all.

>> For strlcpy, we don't care if the destination is a string or not
>> because we overwrite what's in the destination array.
> 
> No, applications that call strlcpy expect it to create a string. For
> example, the design intent is for applications to use strlcpy followed
> by strlcat, and because strlcat (S, ...) assumes that S is a string,
> strlcpy must create a string in S; otherwise the two functions would not
> be the companion functions that they're clearly supposed to be.

I see the value as a post-condition, but I felt that your wording was
using the post-condition as a way to specify a pre-condition an
application has to adhere to, which I think is misleading.

>>>> +The behavior of @code{strlcpy} is undefined if @var{size} is
>>>> nonzero and
>>>> +the source string and the first @var{size} bytes of the destination
>>>> +array overlap.
>>> The phrase "@var{size} is nonzero and" is unnecessary, since a
>>> zero-length array cannot overlap anything.
>> It's okay as far as the formal description of restrict is concerned, but
>> it's not clear with the informal âoverlapâ.

> "overlap" has a standard usage in C11 (one that agrees with the formal
> description of 'restrict'). The use of the phrase "@var{size} is nonzero
> and" implies that our use of "overlap" has a different meaning.

C11 doesn't have zero-sized objects, and I can't find a clear definition
of âoverlapâ either.  That's why I added it.  I'm not really wedded to
it, I just thought it would make things clearer.

Fortunately, we don't have to resolve this dispute if a zero size is
undefined.

Florian