[PATCH v3] Implement strlcpy [BZ #178]

[Rich Felker]

On Mon, Nov 09, 2015 at 06:31:32PM +0000, Joseph Myers wrote:
> On Mon, 9 Nov 2015, Rich Felker wrote:
> 
> > Could you elaborate on when/how there would ever be a technical (not
> > ideologically-motivated) reason to add additional .so's as part of
> 
> Are you saying libinux-syscalls.so.1 is ideologically motivated?

Yes, so far all of the arguments I've seen for it have been that
somebody does not want them in libc.so because they're not the "GNU
API". I haven't seen any technical problem that's solved by putting
them in a separate .so, but of course there are technical problems
created (more memory usage and startup time, etc.).

> libmvec is separate to allow for the possibility of using vector 
> instructions that are only supported by binutils versions more recent than 
> we wish to require as the minimum for a given architecture (this is a 
> generic reason that could apply to multiple architectures) - the ABI 
> provided by a library mustn't depend on the build tool version, but its 
> presence or absence may.

This seems like a legitimate technical concern, but I don't think it's
the right solution. Instructions that aren't supported by the minimum
binutils version probably need to be represented with .byte or similar
until the version requirement is increased. IMO it's the whole
combined API/ABI of all the glibc libs, not just individual libs, that
should be independent of the tools used to build.

Rich