This is the mail archive of the libc-alpha@sourceware.org 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/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

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