Hello all. This message is about bug #412569, but informations are also relevant to issue #200641. I looked deeper into zdump and gmtime issues. And I think there is no error in libc's gmtime or zdump. $ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL $ In my opinion it is actually correct output. Documentation of zdump needs to be updated to fully reflect this strange (but correct) behaviour. Why? -9223372036854775808 is smallest possible time_t value on alpha (-2**63), as time_t on alpha is signed long int (64 bits). Next one is one day later. Similary 9223372036854775807 is biggest possible time_t. This corectly follows documentation of zdump -v option. Why such strange output? Because -9223372036854775808, is more than 2*31 years before 1970. And a tm_year field of struct tm, have type int, which on alpha have 32-bits. So oldest year is -2**31 = -2147483648, and in conlusion oldest possible date/time is 01 Jan 00:00:00 -2147483648 UTC, with value of ``seconds after epoch'' equal -67768040609740800 (somwhere beetwen -2**56 and -2**55). This minus one, already cannot be represented in broken-down time format in struct tm. Similary for maxium date. Cearfully inspecting source code, and adding some debuging to zdump, shows also that gmtime properly sets errno to EOVERFLOW, indicateing it cannot convert data to broken-down format. I suppose gmtime_r will behave in exactly same way. This issues will not happen on architectures with sizeof(int) = 8, as tm_year will be big enugh to fit year -300498215812. (slightly more 2**38 years before 1970). So, also #200641 is not a bug. gmtime is behaving properly, because int is 32-bits, even on 64-bit architectures in our cases (not tested on amd64 just now, but AFAIR, int is still 32-bit also there). I checked POSIX standards and it looks that, current behaviour do not violatate this standards. I also think this is same behaviour as under Solaris. Other solution is to have hardcoded string "01 Jan 00:00:00 -2147483648", or display -67768040609740800 as smallest one (it isn't actually smallest, but smalles which can be printed using gmtime). So in both cases zdump documentation will need to be updated. I personally think we should just document current behaviour. PS. Original bug reports of #412569, do not apply anymore. --version option is working. It still loops, but on any 64-bit computer I tested, it exit after about 3 to 9 seconds. And it do not crash anymore in any case. Regards, Witek -- Witold Baryluk JID: witold.baryluk // jabster.pl
Attachment:
signature.asc
Description: Digital signature