zdump -v segfault on alpha
tz. at explicate.org
Wed Feb 28 09:33:51 UTC 2007
On Wed, Feb 28, 2007 at 08:03:33AM +0100, Gilles Espinasse wrote:
> I use strace against debian version
> read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 8192) = 1082
Because that is TZif\0 instead of TZif2, I strongly suspect that the
version of tzcode used by this release of Debian was before proper
support for 64-bit time_t values was added. What is the output of
this command (fix the path if Debian installed zdump somewhere else):
strings /usr/sbin/zdump | grep '@(#)'
> Concerning zdump 8.3, I should say I did not wait enough time to see the
> full output
> That's because after the first two lines, nothing is printed during half a
> minute. Then depending of the timezone setting, more is displayed
Yeah, that's becaue zdump.c:delta() actually steps through time
year-by-year from the minimum to the maximum representable years.
This is a simple and reliable method, and with a 32-bit time_t
it is fast enough to not be worth using a less-obviously-correct
algorithm, but for a 64-bit time_t it does seem a bit silly.
On the other hand, getting it _right_, avoiding calculation overflows
and allowing for all the different types that time_t might have is
a bit of chore, and since zdump -v is run infrequently it hasn't
yet been worth the effort to fix this.
More information about the tz