Hello,
We have detected a small bug in the clock function used
inside the nmh function to format the date. Our nhm version
is 1.0.4
From this Saturday Sept 8th, 2001 the unix
timestamp it is 10 decimal digits long, and the
clock operator (number of second from the Unix Epoch)
fails.
If you use the following command:
scan +inbox -format "%{Date} -- %(clock{Date})"
.......
Fri, 07 Sep 2001 11:16:51 +0200 -- 999854211 -- 538289
Fri, 7 Sep 2001 11:45:32 +0200 -- 999855932 -- 536568
Fri, 07 Sep 2001 16:37:37 +0200 -- 999873457 -- 519043
Fri, 07 Sep 2001 22:30:00 -- 999898200 -- 494300
Sat, 8 Sep 2001 13:23:41 +0200 (MET DST) -- 999948221 -- 444279
Mon, 10 Sep 2001 08:44:42 +0200 (MET DST) -- 709260928 -- 288218
Mon, 10 Sep 2001 10:22:26 +0200 -- 709265087 -- 282354
Mon, 10 Sep 2001 12:27:28 +0200 -- 709270407 -- 274852
Mon, 10 Sep 2001 17:37:17 +0200 -- 70928358= -- 256263
.......
with messages later than Sept 8th you will see
wrong times for the messages.
The problems it is in the PUTD macro defined in this file.
The macro used two integers i, c to store temporary values
and one of them (c) is overflowed.
One quick fix is to define c and i vars as "long long int"
(64bits integer), in the fmt_scan function .
.............
./scan +inbox -format "%{Date} -- %(clock{Date})"
Fri, 07 Sep 2001 11:16:51 +0200 -- 999854211
Fri, 7 Sep 2001 11:45:32 +0200 -- 999855932
Fri, 07 Sep 2001 16:37:37 +0200 -- 999873457
Fri, 07 Sep 2001 22:30:00 -- 999898200
Sat, 8 Sep 2001 13:23:41 +0200 (MET DST) -- 999948221
Mon, 10 Sep 2001 08:44:42 +0200 (MET DST) -- 1000104282
Mon, 10 Sep 2001 10:22:26 +0200 -- 1000110146
Mon, 10 Sep 2001 12:27:28 +0200 -- 1000117648
Mon, 10 Sep 2001 17:37:17 +0200 -- 1000136237
Mon, 10 Sep 2001 20:34:09 -0400 (EDT) -- 1000168449
Tue, 11 Sep 2001 05:10:05 +0200 (MET DST) -- 1000177805
.............
I don't know if this fix it is portable for old platform
than don't have a 64 bit integer.
