This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]