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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 5 Jan 2016 19:18:09 +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> <568B1587 dot 4030905 at cs dot ucla dot edu>
On 01/05/2016 01:59 AM, Paul Eggert wrote:
> On 01/04/2016 12:55 PM, Florian Weimer wrote:
>
>> I think it should say âif the source string and destination array
>> overlapâ.
>
> That sounds good. Any such usage is likely an application bug.
>
>> We can probably ditch the size-0 documented special case for strlcat
>> (where it is just extremely confusing and not very helpful), but not for
>> strlcpy, where it is part of the specification.
>
> The phrase "part of the specification" begs the question, no? We are
> discussing what should be in the glibc spec if we add strlcpy+strlcat.
We need to compatible with as many of the implementation we replace as
possible. This is the burden we have because we are so late to provide
this function.
> There is no standard spec to appeal to, as size-zero and NULL strlcpy is
> an area where the BSD implementations and documentation are confused and
> in some cases disagree, and likewise for strlcat.
I think the size-zero buffer is quite clear from the original
description of strlcpy. Things are more messy with strlcat, I will
grant that.
> Besides, it would be strange to define size-zero strlcpy while leaving
> size-zero strlcat undefined. They're supposed to be companion functions,
> typically used on the same output buffer, so why should one work while
> the other has undefined behavior? The same issue that makes size-zero
> strlcat dubious (namely, the destination is not a string) also makes
> size-zero strlcpy dubious.
I think the last part is not actually true. For strlcpy, we don't care
if the destination is a string or not because we overwrite what's in the
destination array.
>> +The behavior of @code{strlcpy} is undefined if @var{size} is nonzero and
>> +the source string and the first @var{size} bytes of the destination
>> +array overlap.
>
> The phrase "@var{size} is nonzero and" is unnecessary, since a
> zero-length array cannot overlap anything.
It's okay as far as the formal description of restrict is concerned, but
it's not clear with the informal âoverlapâ.
Florian