This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixing namespace issues for variables
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 23 Oct 2015 12:13:49 +0000
- Subject: Re: Fixing namespace issues for variables
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1510222324130 dot 23141 at digraph dot polyomino dot org dot uk> <562A06AB dot 5080608 at redhat dot com>
On Fri, 23 Oct 2015, Florian Weimer wrote:
> For real global variables, this isn't pretty, but I think it is
> acceptable (if the ELF specifics work out, including size changes, which
signgam is an int; there's no reason for its size to change. If
re_syntax_options changes size various functions would need new symbol
versions anyway and I don't see a problem with a new version of
__re_syntax_options_location in that case.
> I don't know). Such global variables are legacy anyway due to thread
> safety, so the additional performance overhead would not matter.
>
> Constants are another matter. We might need something else for them if
> applications can expect fast access.
If a variable is read-only (and its contents are what matters, not its
address) then it's not a problem for the main program and libc to end up
using different copies (it doesn't even waste memory - both copies are
always allocated even if only one is used), so aliases can be used in the
same way as for functions. Cf. my fix for in6addr_*
<https://sourceware.org/ml/libc-alpha/2015-06/msg00484.html>.
--
Joseph S. Myers
joseph@codesourcery.com