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

[Alexander Cherepanov]

On 2016-01-05 14:09, Florian Weimer wrote:
> On 01/05/2016 01:02 AM, Alexander Cherepanov wrote:
>
>>> +The behavior of @code{strlcpy} is undefined if @var{size} is zero, or
>>> +if the source and destination strings overlap.
>>>
>>> I think it should say “if the source string and destination array
>>> overlap”.   There is no destination string before the call.  I don't
>>> think it's necessary to make the special case defined where the source
>>> string is part of the destination array, but not located close to the
>>> beginning so that the actual copy will not overlap.  This is simply too
>>> subtle.   I think it is undefined for snprintf (“If copying takes place
>>> between objects that overlap, the behavior is undefined.”),although
>>> this does not necessarily follow from the restrict qualify (based on my
>>> somewhat shaky understanding of restrict).
>>
>> IIUC you are saying that this code:
>
> No, my point was that this code:
>
>    char s[10];
>    strcpy (s + 5, "abc");
>    snprintf (s, sizeof (s), "%s", s + 5);
>
> is invalid.

Then my example is even more invalid (according to this logic).

> This depends on what “objects” means in “If copying takes
> place between objects that overlap, the behavior is undefined.”

Ok

>>    char s[10];
>>    snprintf(s, -1, "%s", "abc");
>>
>> is invalid. IMHO this is wrong. The description of snprintf in C11
>> doesn't mention size of the destination array or talk about any
>> connection between n and s at all, it just says that characters beyond
>> the (n-1)st are discarded.
>
> POSIX, on the other hand, speaks of the “n argument which states the
> size of the buffer referred to by s”.

I'm not sure what you mean. That POSIX differs from ISO C and should be 
preferred here? Or that POSIX just describes the same in more details 
and that ISO C actually means the same? Or that authors of 
strlcpy/strlcat talked about the POSIX flavor of snprintf in their doc? 
Or something else?

Also: http://austingroupbugs.net/view.php?id=1020 .

> POSIX also requires that the -1
> argument results in -1/EOVERFLOW result,

Yeah, clear contradiction with ISO C.

> but this does not apply to
> strlcpy because it has a size_t (not int) result.
>
> I'm not sure what the intent behind these specifications is.  I would
> certainly prefer that size arguments must denote object sizes.
> Everything else is just extremely confusing.

Ok, I'm confused. I can see at least 3 different parts in drafting the 
specification of strlcpy/strlcat for glibc:
1) what was required/guaranteed by original strlcpy/strlcat,
2) what glibc is willing to break from it,
3) what glibc wants to add on top of it.

When you talk about snprintf analogy is it 1 or 3?

Which sources do you consider authoritative for 1? OpenBSD man page counts?

My impression was that snprintf analogy is in 1. And that this means 
that @var{size} is not required to be the size of the array.

> For example, I don't expect
>
>    read (fd, ptr, SSIZE_MAX)
>
> to succeed as long as the actual number of bytes read is sufficiently
> small (and it fails with EFAULT on Linux).

You mean that it violates POSIX and you like it? Hm...

I guess opinions will differ (as we have already seen with 
malloc(SSIZE_MAX+1)). But I would expect that all places where glibc 
intentionally deviates from the standards to be marked (at least). Are 
there such places already?

-- 
Alexander Cherepanov