This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] Implement strlcpy [BZ #178]
- From: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Tolga Dalman <tolga dot dalman at googlemail dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Mon, 9 Nov 2015 14:16:09 -0500
- Subject: Re: [PATCH v3] Implement strlcpy [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <56326B79 dot 8070804 at redhat dot com> <20151105211104 dot D10932C3B22 at topped-with-meat dot com> <20151106040125 dot GY8645 at brightrain dot aerifal dot cx> <563C9871 dot 9090700 at linaro dot org> <563E9BE6 dot 40508 at googlemail dot com> <20151108010732 dot GH3818 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1511091256260 dot 26853 at digraph dot polyomino dot org dot uk> <20151109181635 dot GP3818 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1511091817320 dot 18468 at digraph dot polyomino dot org dot uk>
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