[tz] question regarding 'timezone' variable

[Paul Eggert]

Kees Dekker wrote:
> My concerns are:
>
> a.       The provided variable in localtime.c may conflict with the system one.

Their types shouldn't conflict, as the type is standard.  If the types actually 
do conflict it's a bug, and we should fix it, but I don't know of any such 
conflicts.

In most production libraries the linkages of the variables do not conflict 
either, because the library definitions are weak.  Even with old-fashioned 
libraries that do not use weak symbols (are there are any? you can't build a 
standard C system without them...), so long as localtime.c defines all the 
functions and variables that the corresponding library modules define we're 
fine, because the corresponding library modules will not be pulled in and our 
functions and variables will be used everywhere, as they should be.

> b.      The used variable in strftime.c may not related to the variable in localtime.c
>
> Question: Is behavior intended? Or do I miss something?

The behavior is intended, in the sense that localtime.c is intended to be a 
complete implementation of the Unix library's time-related functions (other than 
system calls) and variables, and is intended to replace the Unix library's 
modules when linked into a C program.

> I think that compilers/linkers may complain about duplicate 'timezone' variables, or probably silently map the local timezone variable to the same one.

The latter is intended.  In practice the former doesn't seem to happen for 
reasons mentioned above.

That being said, I can see one weird situation where it'd be a win to remove 
those variables' initializations.  If you're in a system that uses the "Common" 
linkage model (see the C standard rationale), and if localtime.c says "long 
timezone;" and a system library module also says "long timezone;", and if the 
system library module defines some function F that we don't, and if F is used by 
the program, and if the system library module doesn't use weak symbols, then 
things will still work.  But if localtime.c says "long timezone = 0;" the linker 
will complain about multiple definitions.  So under this hypothetical 
environment (which we've never seen and aren't likely to), the attached proposed 
patch would be beneficial.  Also, the attached patch saves a few words in 
traditional object modules, so it's a minor win for that reason anyway.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-unnecessary-static-initializations.patch
Type: text/x-diff
Size: 1473 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20150831/6ce9c923/0001-Remove-unnecessary-static-initializations.patch>