[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#200641: zdump -v on alpha (and other 64-bit archs), and gmtime

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.


-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.


Witold Baryluk
JID: witold.baryluk // jabster.pl

Attachment: signature.asc
Description: Digital signature

Reply to: