Fixing namespace issues for variables
Florian Weimer
fweimer@redhat.com
Fri Oct 23 10:06:00 GMT 2015
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.
Florian
More information about the Libc-alpha
mailing list