[tz] question about mktime_tzname()
Kees.Dekker at infor.com
Mon Jan 16 10:15:50 UTC 2017
One example: printf("%*s", strlen(str), str) width specifier requires int type for the width (according printf() definition for width specifiers), but if strlen or sizeof is used as input, then a 64-bit value is passed to printf. Depending on whether a platform is big or little endian, the 4 bytes read by printf may or may not show the intended value, but even worse, the stack is out-of-sync. If strlen() returns 8 bytes, printf just reads 4 and str is not at the right place. I'm not familiar with all platform details. So I don't know whether a stack may or may not contain 64-bit values only on 64-bit platforms. A number of warnings is related to strlen()/sizeof()/size_t type, but used as int.
From: Kees Dekker
Sent: Friday, January 13, 2017 22:03
To: Paul Eggert <eggert at cs.ucla.edu>; Arthur David Olson <arthurdavidolson at gmail.com>
Cc: Time Zone Mailing List <tz at iana.org>
Subject: RE: [tz] question about mktime_tzname()
Thanks for your explanation and sharing this git knowledge (I'm a newbie regarding git). My surprise was mainly because zdump.c includes private.h, its code is thus shipped together with zdump.c, and still some code of private.h is duplicated. Anyhow, I'm a guest user, so I will off course respect your choice. I just shared my own surprise (no offence or disrespect intended). It is probably also somewhat a personal choice to choose between a false alarm warning on int a = strlen(str) (warning in 64-bit mode) and to use int a = (int)strelen(str) if we no for sure that str will never exceed max-signed-int. In our own code, we often use a code like if strlen(str) exceeds max-signed-int, then call assert(). Still not perfect, but if a value unintentionally exceeds an expected limit, you will get an abort/core dump. Even in the case of not using a cast, at runtime an overflow is silently ignored and may result in unexpected behavior. But again, I'm 'guest user' of your code.
I have to live with more platforms, as our product runs on it. In much regards, gcc is a 'perfect' compiler, but sometimes other platforms complain about other things (not covered by gcc). Each platform has its own odd things. I like to limit these changes to an absolute minimum, but may ask you to solve some. The world is not limited to Linux/gcc only :-).
Van: Paul Eggert [eggert at cs.ucla.edu]
Verzonden: vrijdag 13 januari 2017 16:55
Aan: Kees Dekker; Arthur David Olson
CC: Time Zone Mailing List
Onderwerp: Re: [tz] question about mktime_tzname()
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:
which was fixed as described in:
> 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:
This does not generate false alarms with recent GCC, which is the only
platform for which I worry about false alarms.
More information about the tz