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

[Alexander Cherepanov]

On 2016-01-05 10:06, Paul Eggert wrote:
>> Are you seriously arguing for glibc not to comply with C11?
>
> Naaah.And on second thought, my comment was based on a backwards
> interpretation of the POSIX spec: that spec places extra constraints on
> the implementation not on the application. So please forget my mistaken
> comment about POSIX snprintf.

Sorry, I don't understand what you mean. Your first reading of POSIX 
seems quite reasonable to me. And that reading conflicts with C11 so I 
reported it in http://austingroupbugs.net/view.php?id=1020 .

>> descriptions (e.g. [2], [3]) of strlcpy and strlcat refer to C9X or BSD,
>> not to POSIX. So it's not relevant to the current discussion.
>
> Yes and no. I think Florian is arguing that strlcpy should act like
> snprintf, and so in that sense it's relevant. However, I agree with you
> that snprintf is not an exact analog and is not a good precedent for
> strlcpy.

It's not just Florian arguing about snprintf, it's the original article 
about strlcpy/strlcat referring to snprintf and OpenBSD man page 
unambiguously stating:

| Besides quibbles over the return type (size_t versus int) and signal
| handler safety (snprintf(3) is not entirely safe on some systems),
| the following two are equivalent:
|
|   n = strlcpy(dst, src, len);
|   n = snprintf(dst, len, "%s", src);

What I meant in my previous email is that these descriptions referred to 
C9X and BSD flavors of snprintf, not to the POSIX one. But now that we 
are agree to ignore POSIX for a moment, this detail is not important.

>> do you think the fact that @var{to} and @var{from}
>> overlap makes the code:
>>
>>    char s[10] = "abc";
>>    strncat(s, s, 2);
>>
>> is invalid even though there is no overlapping copying?
>
> I don't think strncat is an exact analog for strlcat either. That is,
> although I agree that the strncat example has well-defined behavior in
> C11, this is not precedent for strlcat, any more than snprintf would be.
> They're just different functions, that's all.
>
> For example, it'd be reasonable for strlcpy to verify that every byte in
> the destination array is writeable. That could help catch bugs in
> programs. The spec should not disallow such an implementation.

Ok, I guess it boils down to the question which sources are considers 
authoritative for describing strlcpy/strlcat? Is OpenBSD man page included?

-- 
Alexander Cherepanov