Re: Fixing namespace issues for variables

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 24 Oct 2015, Rich Felker wrote:

> > When I tried and failed to use aliases, it was for stdin / stdout / 
> > stderr, with the main name used internally being hidden.  As noted in 
> > <https://sourceware.org/ml/libc-alpha/2015-10/msg00876.html> I've since 
> > located the linker magic that allows such aliases to work *if the internal 
> > name is exported* (so this provides yet another reason to need non-compat 
> > internal-namespace exports at public symbol versions, beyond uses in 
> > macros, inline functions, libc_nonshared, libgcc, libstdc++ etc.).  As 
> > also noted there, since __signgam was not an exported symbol alongside 
> > signgam in glibc 2.0, use of aliases like that would break existing 
> > binaries, as existing binaries would preempt only signgam and so break the 
> > aliasing.
> 
> Yes. This is the traditional way things were always intended to work.

Apparently not traditional enough to have anything in the gABI that I 
could find saying that in this particular case special treatment should be 
given when two symbols are at the same address.  I have no idea if this is 
actually portable across ELF linkers in practice.

> > Furthermore, address comparison is not a solution as I hoped for 
> > distinguishing old and new binaries.  When I said that programs defining 
> > their own tzname don't get it bound to the glibc symbol, I meant that the 
> > dynamic tzname symbol from the executable was unversioned.  But an 
> > unversioned symbol from an executable will still preempt a versioned 
> > symbol from glibc (necessarily; recall that glibc 2.0 didn't have symbol 
> > versioning, so you can't distinguish an unversioned signgam definition 
> > from a binary linked with glibc 2.0 using the library's signgam from one 
> > from a new binary defining its own), and so &signgam == &__signgam would 
> > return false for the new binary as well as the old one.
> 
> I don't see how versioning is relevant here. If the main program

Because ideally any reference to a glibc symbol would be properly 
versioned (so a binary referencing signgam at version GLIBC_2.0 
unambiguously wants it set by lgamma, and a binary where it is unversioned 
is unambigously doing its own thing with that symbol name, and, within 
glibc, an unversioned signgam symbol from the executable simply wouldn't 
be visible with the name signgam at all).  But because unversioned symbols 
can bind to glibc symbols (and because this is necessary to support since 
glibc 2.0 predated symbol versioning support), this doesn't work, and it's 
not possible to distinguish the two cases just by properties of the 
signgam and __signgam symbols without also adding new versions of lgamma 
functions.

> Reservation as macros is not relevant. You're always allowed to
> undef the macro and use the underlying object/function unless the
> identifier is actually _specified_ to be a macro. It's non-conforming

No, that's simply not what POSIX says.  It says "Identifiers in 
POSIX.1-2008 may only be undefined using the #undef directive as described 
in Use and Implementation of Interfaces or The Name Space. These #undef 
directives shall follow all #include directives of any header in 
POSIX.1-2008.".  That is, no #undef of a standard header's macro unless 
explicitly permitted.  Use and Implementation of Interfaces gives such 
permission for macro definitions of functions, while The Name Space gives 
such permission for macros beginning with certain prefixes (for <math.h>, 
the only prefix with such permission is FP_[A-Z]).

-- 
Joseph S. Myers
joseph@codesourcery.com