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 10/23/2015 02:12 AM, Joseph Myers 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:
> extern int *__signgam_location (void);

You could add __attribute__ ((pure)), I think.

> #define signgam (*__signgam_location ())
> __signgam_location would be a new dynamic symbol exported from libm.  The 
> existing signgam export from libm would become a compat symbol.
> In static libm, and shared libm for new ports, the variable signgam would 
> simply be renamed to __signgam, and we'd have:
> int *
> __signgam_location (void)
> {
>   return &__signgam;
> }

For real global variables, this isn't pretty, but I think it is
acceptable (if the ELF specifics work out, including size changes, which
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.


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