From patchwork Tue Jan 5 00:59:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paul Eggert X-Patchwork-Id: 10221 Received: (qmail 84702 invoked by alias); 5 Jan 2016 00:59:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 84200 invoked by uid 89); 5 Jan 2016 00:59:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=appeal, dubious, disagree, null-terminated X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178] To: Florian Weimer References: <5682DD7E.6000301@redhat.com> <56839678.8040304@cs.ucla.edu> <568ADC5F.5010608@redhat.com> Cc: GNU C Library From: Paul Eggert Message-ID: <568B1587.4030905@cs.ucla.edu> Date: Mon, 4 Jan 2016 16:59:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <568ADC5F.5010608@redhat.com> 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