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:24:24 +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> <alpine dot DEB dot 2 dot 10 dot 1510231208100 dot 29157 at digraph dot polyomino dot org dot uk> <562A2592 dot 7050102 at redhat dot com>
On Fri, 23 Oct 2015, Florian Weimer wrote:
> On 10/23/2015 02:13 PM, Joseph Myers wrote:
> > 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.
>
> I was worried about a conflicting size for an interposed definition in
> the main program. This concern applies to an alias-based solution as
Well, with my solution for signgam new programs won't get their signgam
symbol bound to glibc's at all, because glibc's will be a compat symbol,
so the two will be completely independent.
With aliases, the symbol might end up pointing at runtime to the
wrong-size symbol in the user's program, but if it was valid for the
user's program to define that symbol then libc will never use that
wrong-size copy (as the internal name used internally in libc will always
point to libc's own copy).
--
Joseph S. Myers
joseph@codesourcery.com