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

[Paul Eggert <eggert at cs dot ucla dot edu>]

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. :-)
diff --git a/manual/string.texi b/manual/string.texi
index f0fe7d3..3d2fff3 100644
--- a/manual/string.texi
+++ b/manual/string.texi
@@ -1118,14 +1118,11 @@ If @var{size} is nonzero and less than or equal to the the length of the string
 bytes to the destination array @var{to}, and writes a terminating null
 byte to the last byte of the array.
 
-If @var{size} is zero, @code{strlcpy} does not modify the destination
-array, and @var{to} can be a null pointer.
-
 The return value @var{result} of @code{strlcpy} is the length of the
 string @var{from}.  This means that @samp{@var{result} >= @var{size}} is
 true whenever truncation occurs.
 
-The behavior of @code{strlcpy} is undefined if @var{size} is nonzero and
+The behavior of @code{strlcpy} is undefined if @var{size} is zero, or if
 the source string and the first @var{size} bytes of the destination
 array overlap.
 
@@ -1133,8 +1130,8 @@ As noted below, this function is generally a poor choice for processing
 text.  Unlike @code{strncpy}, @code{strlcpy} requires @var{size} to be
 nonzero and the source string to be null-terminated, computes the
 source string's length, ensures that the destination is
-null-terminated (assuming that @var{size} is nonzero), and does not
-fill the remaining part of the destination with null bytes.
+null-terminated, and does not fill the remaining part of the destination
+with null bytes.
 
 This function is derived from BSD.
 @end deftypefun