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: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â.


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