Re: Fixing namespace issues for variables

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 24 Oct 2015, Rich Felker wrote:

> > So simply using aliases is not a solution in the case of data symbols.  
> > The solution I propose instead is as follows.  math.h would (under 
> > appropriate feature test macros) do:
> 
> I don't follow. How is this any different from environ, timezone,
> daylight, etc.? They are all handled correctly by an alias; when
> linking produces copy relocations, the linker does the right thing
> automatically and preserves the aliasing.

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.

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.

So you'd need at least four new public symbols (__signgam, plus new 
versions for lgamma, lgammaf, lgammal; gamma* could be kept pointing to 
old versions, which would have to set both __signgam and signgam in case 
the aliasing was broken) to do things with aliases.  It might still be 
safer than __signgam_location, but we want to be sparing with public ABIs.  
(stdin / stdout / stderr would be much worse to do with versioning 
functions, but there macro definitions are unambiguously OK.)

> > extern int *__signgam_location (void);
> > #define signgam (*__signgam_location ())
> 
> This is non-conforming. POSIX requries an extern object. Note that the
> rule about being able to use the interface without including the
> header applies to most of the interfaces in math.h.

That rule is for *functions* (with certain types), not *variables*.  
POSIX seems silent on being able to use non-function interfaces like that 
(and as I said in my mail to the Austin Group list, the missing 
reservation as macros for all file scope identifiers seems a clear mistake 
in updating POSIX for C99).

-- 
Joseph S. Myers
joseph@codesourcery.com