Reason for __ aliases of variables

[Florian Weimer <fweimer at redhat dot com>]

We have some global variables in glibc which have internal __ aliases 
(e.g., daylight and __daylight).  Why do we do this?

We cannot optimize access to the __ variant because that would break the 
aliasing (__daylight in libc.so.6 and daylight in the application would 
be different objects, breaking the interface).

If the application defines the non-__ variable, we still need to write 
to it through the __ alias, so there is no namespace protection (again, 
doing otherwise would break the interface).  Some relocation types are 
indistinguishable at the ELF layer from a variable definition supplied 
by the application (so saying “int daylight = 5;” is invalid doesn't 
help much).

So it's probably best to get rid of these aliases (but only for new 
ABIs, we cannot even turn __daylight into a compat symbol because that 
would be treated as hidden (although it obviously is not) and triggers 
an error from ld).

Should we switch the internal use of __ symbols to the names without the 
__ prefix?

If we make internal calls which happen to rely on these symbols without 
an explicit dependency specified by POSIX, we should probably have 
different implementations which do not access these variables.  This 
would also allow us to avoid a thread safety hazard.

Thanks,
Florian