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

[Alexander Cherepanov]

On 2016-01-06 02:07, Florian Weimer wrote:
> On 01/05/2016 10:20 PM, Alexander Cherepanov wrote:
>
>>> 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?
>
> My point is that we are reading too much into those texts.  I can only
> assume that the POSIX authors assumed their formulation was equivalent
> when it clearly is not.  This means that some clarification is needed
> (both in ISO C and POSIX) to decide what we really want (which, at this
> stage should be what existing implementations do, if they are aligned,
> but people working standards have sometimes different ideas about how to
> deal with such ambiguities), or if things should be left unspecified or
> implementation-defined.

I don't think this is applicable to ISO C in this particular case. In 
questions "size of object vs. number of chars to copy" and "string vs. 
non-null-terminated array" it seems quite accurate and consistent. I 
doubt there is a chance to change something here. There even was a 
movement in the direction opposite to what you want -- it was clarified 
in C11 for memchr that an implementation cannot go further after a 
matching character is found (s.a. glibc bug 19406).

OTOH POSIX is quite sloppy in this area. Apart from the snprintf issue, 
I recently reported a strndup issue -- 
http://austingroupbugs.net/view.php?id=1019 . I mainly aimed at 
consistency with other strn* functions, maybe you want to chime in with 
other considerations.

Sure, C11 has its own problems, bugs and crazy defect reports but IMHO 
they are more advanced.

>>> 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?
>
> 1) for strlcpy.  For strlcat, I don't think anymore I can make this case.
>
>> Which sources do you consider authoritative for 1? OpenBSD man page counts?
>
> The current (amended) OpenBSD manual page.

Ok, thanks.

>> 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.
>
> Doesn't OpenBSD snprintf has the bounded pointer check?

Whether they calculate s+n? AFACT no but it's possible that I missed it.

>>> 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 don't think it violates POSIX.  I think the text was not written with
> this level of exegesis in mind.

Maybe. I don't have enough experience with POSIX to judge it. But the 
problem with such POV is that a standard, once published, starts to live 
its own life. No matter what its authors thought or intended other folks 
work with the published text.

OTOH, is this intentional behavior of read on Linux? Is there a 
consensus around it? If yes, why not submit it to POSIX?

-- 
Alexander Cherepanov