[tz] question about mktime_tzname()

[Paul Eggert]

On 01/13/2017 05:24 AM, Kees Dekker wrote:
> I discovered that zdump.c was updated, and now got additional code from private.h. Why? 

The command "git log zdump.c" can help you answer questions like that.
It points to:

http://mm.icann.org/pipermail/tz/2016-December/024721.html

which was fixed as described in:

http://mm.icann.org/pipermail/tz/2016-December/024722.html

> I'm busy porting the code to Windows, and now see duplicate stuff, but private.h is already included in zdump.c. It is not a big problem (but in general, I like to avoid duplicating stuff);

zdump is intended to be buildable without the rest of the tz source
code, and so does not assume any internals of private.h. That being
said, it uses some of the same style as the tz source code and so needs
some of private.h's definitions when these definitions work on any
time_t implementation. Perhaps private.h should be split into two (a
portable part, and a non-portable part), but it's not high priority.


> I just have to apply some changes that I already applied myself to private.h. In this case: Visual Studio is not setting STDC_VERSION but adheres more or less to STDC (at least, has stdbool.h).

The tz code should work fine the way it is, no? That is, Visual Studio
will work just fine with the stdbool.h substitute that is in private.h
and zdump.c. If so, there's no need to insist that Visual Studio include
stdbool.h and I'm inclined to leave the code alone. The goal is to run
on nonstandard platforms, not to cater to their every nook and cranny.

> Another point of attention is mixing size_t (e.g. result of strlen()) and int. Complaining compilers, especially in 64-bit mode, will raise an warning or error when mixing these types (regarless the tz code will never return a strlen() value that will exceed a signed 32-bit value).

There are many such false alarms, and pacifying every compiler's false
alarms would take too much maintenance effort and contort the code too
much. Instead, please ignore the false alarms, or use compile-time
options that suppress them.

>  I will try to resolve these 64-bit warnings (the Makefile provided with the tzcode still uses a default mode of the compiler. As far as I know, this is 32-bit on most platforms. Changing CFLAGS to -m64 -Wall -Wextra will also show a lot of warnings on e.g. Linux).

Yes, and those are all false alarms too. On GNU/Linux I suggest using
these compile-time flags instead:

make CFLAGS='$(GCC_DEBUG_FLAGS)'

This does not generate false alarms with recent GCC, which is the only
platform for which I worry about false alarms.