This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fixing namespace issues for variables

On Fri, Oct 23, 2015 at 12:12:22AM +0000, Joseph Myers wrote:
> We have some bugs where library functions use a global variable outside 
> the namespace of some standards containing those functions, interfering 
> with programs' own use of variables by that name.  These are currently 
> whitelisted in  I'll use signgam (bug 15421) as the 
> example in what follows (ISO C includes lgamma but not signgam), but the 
> same applies equally to other cases of this issue.
> Normally namespace issues could be fixed by making the problem symbol into 
> a weak alias for an implementation-namespace symbol and using the 
> implementation-namespace symbol internally.  However, this doesn't work 
> for data symbols.
> A non-PIC program using signgam - whether it defined its own copy with 
> "int signgam;" or referenced libm's copy with "extern int signgam;" or via 
> the declaration of signgam when <math.h> is included under some conditions 
> - uses it with non-PIC code sequences appropriate to a copy of the 
> variable located directly in that program.  When the program is linked, it 
> then defines a dynamic symbol signgam (at the appropriate symbol version 
> from glibc), and the dynamic linker makes this preempt the signgam symbol 
> from libm, so that all references to signgam from within libm end up 
> referring to the copy from the main program (there may also be a copy 
> relocation to copy the initializer from libm to the copy in the main 
> program).  If any reference from within libm uses a different name, that 
> reference does not get preempted, meaning that the two symbols that were 
> aliases when libm was linked are no longer aliases at runtime.
> 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.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]