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: Joseph Myers <joseph at codesourcery dot com>
- To: Rich Felker <dalias at libc dot org>
- 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 18:31:32 +0000
- 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>
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?
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 reasoning does *not* work for powerpc
float128 functions - quite clearly TS 18661-3 functions belong in
libc/libm rather than another library, since many would be aliases of
existing functions, so float128 functions can only be added to glibc for
an architecture when there's consensus on a suitable minimum GCC version
for building libc for that architecture.)
If libdfp were merged into glibc we'd need to consider carefully whether
separate libraries or libc + libm were the way to go. Cf.
<https://gcc.gnu.org/ml/gcc-patches/2008-08/msg00870.html> regarding DFP
support in libgcc being static-only to avoid making libgcc_s 8 times
bigger for rarely used functionality (also raising concerns there about
number of runtime relocations and size of writable segment, though without
answers there).
--
Joseph S. Myers
joseph@codesourcery.com