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

[Paul Eggert]

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. 
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. As any application 
usage of these weird corner cases for either strlcpy or strlcat likely 
indicates a bug, it'd be good to make it undefined in the glibc spec.

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.

> +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. The phrase should be removed, 
but better yet the spec should simply disallow size-zero destinations.

I'm attaching a diff against the diff you sent, to highlight this 
remaining issue in the spec.  (I prefer the shorter and simpler version. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strlcpy.diff
Type: text/x-patch
Size: 1447 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160105/faa2c76d/attachment.bin>