[tz] question regarding 'timezone' variable

[Kees Dekker]

Hi Paul,

Thanks for clarification.

But why not then add an 'extern long timezone' line in either both localtime.c and strftime.c or in a header file of the olson code?
That will probably better express that the variable 'timezone' is not of the tzcode library, but is assumed to be a global symbol, somewhere in the system libraries.

I can imagine a bad scenario, i.e. mixing tzcode and system libraries, where tzcode (in localtime.c) adjusts the timezone variable, where after the end user uses system functions that use the same variable.
In any case, this can be considered as bad programming if it is related to own source code, but it is out of the scope of control of programmers if the same happens by system functions that use implicitly the timezone variable under the hood.

It would probably a clearer rule to say: either use olson tzcode, or use system libraries, and they both can be mixed, but should not affect each other. I.e. then the timezone variable should be renamed to a unique name, e.g. olson_timezone, and both localtime.c and strftime.c should use them. The disadvantage is that some Linux variants have to map the timezone variable to olson_timezone, because they you the tzcode variant in their system libraries. But that can be addressed by Linux engineers that rename/define #define olson_timezone timezone :-).

If I understand the tzcode well, the timezone variable only affects strftime() when called with '%z' format speficier. So the effect is probably quite limited.

Regards,
Kees

-----Original Message-----
From: Paul Eggert [mailto:eggert at cs.ucla.edu] 
Sent: Monday, August 31, 2015 15:46
To: Kees Dekker; tz at iana.org
Subject: Re: [tz] question regarding 'timezone' variable

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.