[PATCH v3] Implement strlcpy [BZ #178]

[Zack Weinberg]

On 11/09/2015 01:16 PM, Rich Felker wrote:
> On Mon, Nov 09, 2015 at 12:59:25PM +0000, Joseph Myers wrote:
>> On Sat, 7 Nov 2015, Rich Felker wrote:
>>
>>> Anyway, in general, if adding a function to glibc is a bad idea,
>>> adding it in its own separate .so file shipped with glibc is an even
>>> worse idea. There are no advantages and lots of disadvantages.
>>
>> While it's trivially true that "adding a function to glibc is a bad idea" 
>> means it's bad to add it to any library in glibc, existing or new, there 
>> may well be cases where the conclusion is "it's a good idea to add this 
>> function to glibc, but in a new library (which might be might not be 
>> linked in automatically via AS_NEEDED in a .so linker script)".  Cf. 
>> libmvec or the libinux-syscalls.so.1 discussion.  It's just that I don't 
>> see strlcpy, strlcat or explicit_bzero as such cases - I see them as cases 
>> that belong in libc.
> 
> Could you elaborate on when/how there would ever be a technical (not
> ideologically-motivated) reason to add additional .so's as part of
> glibc? I see all the ones we have (esp. libpthread and librt) as
> historical mistakes that have been a perpetual source of problems
> (like programs sticking with the deprecated gettimeofday instead of
> clock_gettime because the latter needed -lrt, and broken weak symbol
> hacks for pthreads like gcc pr57740, pr60662, or libxml2 pr704904)
> that we should aim to eliminate, not duplicate.

FWIW, I tend to agree with this.

zw