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: Tue, 5 Jan 2016 12:09:40 +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>
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. This depends on what âobjectsâ means in âIf copying takes
place between objects that overlap, the behavior is undefined.â
> 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â. POSIX also requires that the -1
argument results in -1/EOVERFLOW result, 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.
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).
Florian