[tz] question regarding 'timezone' variable
eggert at cs.ucla.edu
Mon Aug 31 13:45:42 UTC 2015
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
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...
Size: 1473 bytes
Desc: not available
More information about the tz