This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 6 Jan 2016 00:07:22 +0100
- Subject: Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <5682DD7E dot 6000301 at redhat dot com> <56839678 dot 8040304 at cs dot ucla dot edu> <568ADC5F dot 5010608 at redhat dot com> <568B0824 dot 6000101 at openwall dot com> <568BA474 dot 2030104 at redhat dot com> <568C33A5 dot 8020104 at openwall dot com>
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.
>> 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.
> 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?
>> 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.
Florian