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

[Florian Weimer]

On 12/30/2015 09:31 AM, Paul Eggert wrote:

>> One suggestion is to make a non-terminated buffer undefined, but that
>> breaks
>> the snprintf analogy for size 0 inputs.
> 
> Sorry, what analogy is that? snprintf does not concatenate to a buffer
> directly. What is the practical use case here? How does the use case
> ignore the principle that strlcpy should null-terminate its output?

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.

Apart from that, my only objection to your strlcpy text is this:

+The behavior of @code{strlcpy} is undefined if @var{size} is zero, or
+if the source and destination strings overlap.

I think it should say “if the source string and destination array
overlap”.  There is no destination string before the call.  I don't
think it's necessary to make the special case defined where the source
string is part of the destination array, but not located close to the
beginning so that the actual copy will not overlap.  This is simply too
subtle.  I think it is undefined for snprintf (“If copying takes place
between objects that overlap, the behavior is undefined.”), although
this does not necessarily follow from the restrict qualify (based on my
somewhat shaky understanding of restrict).

I would like to make a similar change to your strlcat text:

+The behavior is undefined if @var{to} does not contain a null byte in
+its first @var{size} bytes, or if the source and resulting destination
+strings overlap.

There, it does make sense to speak of a string, but supporting the
special case where the source overlaps with the destination array, but
not the part that is written, is again very subtle and difficult to tell
apart from the regular overlap.

I'm attaching a new version with the proposed manual edits, on top of
your version.

Has anyone reviewed the current implementation and has comments about that?

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string.texi.patch
Type: text/x-patch
Size: 2168 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160104/1895298e/attachment.bin>