Re: [PATCH 1/2] Implement strlcpy and strlcat [BZ #178]

[Florian Weimer <fweimer@redhat.com>]

* Paul Eggert:

> On 2023-04-20 01:07, Florian Weimer wrote:
>> * Paul Eggert:
>> 
>>>> +extern __typeof (strlcpy) __strlcpy;
>>>> +libc_hidden_proto (__strlcpy)
>>>> +extern __typeof (strlcat) __strlcat;
>>>> +libc_hidden_proto (__strlcat)
>>>
>>> Glibc shouldn't call these functions internally, so let's not export
>>> them to elsewhere in glibc.
>> strlcpy looks like it could be called for implementing %s in
>> snprintf.
>> That seems like a reasonable optimization.
>
> No, because strlcpy must return the length of the source even when
> it's longer than INT_MAX. (This is a botch in the spec which we
> apparently cannot fix.) So there's no way snprintf could use strlcpy
> without hurting worst-case performance.

The possible shortcut only exists in the EOVERFLOW case, otherwise we
need the exact length for the snprintf return value.  I think optimizing
EOVERFLOW is not important.  We will get more benefit from sharing the
strlcpy implementation.

>> I expect someone to rewrite this using word-size accesses fairly soon.
>
> That would be headed in the wrong direction. We should not waste time
> trying to optimize these functions' copying actions, as the
> destinations are invariably so small that our attempts to "optimize"
> will likely hurt performance.

I expect that these optimizations will benefit short strings as well,
similar to the other string functions.

Thanks,
Florian