[PATCH] Add strlcpy, strlcat [BZ #178]

[Florian Weimer]

On 06/17/2017 06:52 PM, Rical Jasan wrote:
> On 06/16/2017 03:25 AM, Florian Weimer wrote:
>> diff --git a/debug/Versions b/debug/Versions
>> index a6628db..3dd0f7f 100644
>> --- a/debug/Versions
>> +++ b/debug/Versions
>> @@ -57,6 +57,9 @@ libc {
>>    }
>>    GLIBC_2.25 {
>>      __explicit_bzero_chk;
>> +  GLIBC_2.26 {
>> +    __strlcpy_chk;
>> +    __strlcat_chk;
>>    }
> 
> Missing brace?

Huh.  Took me a while to see it.  Fixed.

>> diff --git a/manual/string.texi b/manual/string.texi
>> index ac02c6d..963c587 100644
>> --- a/manual/string.texi
>> +++ b/manual/string.texi
>> @@ -1071,6 +1071,79 @@ processing text.  Also, this function has significant performance
>>  issues.  @xref{Concatenating Strings}.
>>  @end deftypefun
>>  
>> +@comment string.h
>> +@comment BSD
>> +@deftypefun size_t strlcpy (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
> 
> Will need to be "@standards{BSD, string.h}" now.

Okay, I tried to address this in the attached patch.

>> +This function is derived from OpenBSD.
> 
> Do you have a version for this?

OpenBSD 2.4, according to:

  https://www.sudo.ws/todd/papers/strlcpy.html

>> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>> +This function appends the string @var{from} to the
>> +string @var{to}, limiting the total size of the result string at
>> +@var{to} (including the null terminator) to @var{size}.
>> +
>> +This function copies as much as possible of the string @var{from} into
>> +the array at @var{to} of @var{size} bytes, starting at the terminating
>> +null byte of the original string @var{to}.  In effect, this appends
>> +the string @var{from} to the string @var{to}.  Although the resulting
>> +string will contain a null terminator, it can be truncated (not all
>> +bytes in @var{from} are copied).
> 
> "may be copied"?

Thanks, applied.

>> +This function returns the sum of the original length of @var{to} and
>> +the length of @var{from}.  This means that truncation occurs unless
>> +the returned value is less than @var{size}.
>> +
>> +The behavior is undefined if the array at @var{to} does not contain a
>> +null byte in its first @var{size} bytes, or if the source string and the
>> +first @var{size} bytes of @var{to} overlap.
>> +
>> +As noted below, this function is generally a poor choice for processing
>> +text.  Also, this function has significant performance issues.
>> +@xref{Concatenating Strings}.  Unlike @code{strncat}, @var{size}
>> +specifies the maximum total size of the result string (including its
>> +null terminator), not the number of bytes copied from the source string
>> +@var{from}.
>> +Also, unlike @code{strncat} this function requires the source and
>> +destination to be null-terminated, computes the source string's
>> +length, and keeps the destination null-terminated.
> 
> Using, "; @pxref{Concatenating Strings}" would help associate that
> reference to the "significant performance issues" more strongly.

Ah, right, Texinfo now allows punctuation after @pxref.

> To alleviate the repetition of "also" and "unlike", I would move the
> comma after the second "Also" after "@code{strncat}".

I dropped the second “also”.

> The line break is also odd for new content.  Collaborative artefact maybe?

Fixed.

>> +This function is derived from OpenBSD.
> 
> The version again, if you have it, would be nice.

See above, OpenBSD 2.4, just like strlcpy.

(In the meantime, I have realized that strlcpy itself is quite similar
to memccpy.)

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug178.patch
Type: text/x-patch
Size: 43990 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170620/1bccd914/attachment.bin>