To Mo DeJung, ref. your comments on my test case, a modified "test
filecmd-17.2 {cmdProc: mtime}":
I have to admit that I don't se any way to make a simple regression test
case that proves my correction right. But there is no doubt that we got a
problem.
We need to look into some theory: The TCL documentation says that "file
mtime" returns seconds since "the epoch". The Jacl implementation is
File.lastModified(), which, according to its documentation, returns
milliseconds since "the epoch". By looking at "now" in the latter terms, we
find that the number of milliseconds is just too large to put into a 32-bit
integer, which is TCL's concept of an integer. What happens is that the
(int) casting on the long result simply cuts off whatever is to the left of
the first 32 bits.
Then the "file mtime" result will jump up and down in a cyclus of 8-9
months where the results will be negative, zero and then positive.
Comparison of the age of two files made within a shorter interval (days)
will most often come out right, although the "file mtime" results always
are wrong. Let me illustrate:
Day 2001-02-03 16:53:26, I produced a file. Day 2001-02-05 20:07:08
(approximately), I ran my version of the "filecmd-17.2" test, which changed
the timestamp of the file.
Decimal Hexadecimal
Stamp 1 981215606 * 1000 = 0xe47501f4f0
Stamp 2 981400028 * 1000 = 0xe480000360
Running this test with the un-corrected Jacl gives this trace print:
old / new: 1963062512 / -2147166784
Looking at the time stamps chopped down to 32-bit signed integers makes
sense:
0x7501f4f0 = 1963062512
0x80000360 = 2147484512
The reason day 2001-02-05 20:07:08 is interesting is that this is one of
these times where bit 32 turns on (from 0xe47ffffffff to 0xe480000000) and
the the result from the un-corrected version turns negative. The next time
this will happen must be when the clock turns 0xe580000620, which is Mar
27 14:09:56. You can try this out:
981400028 * 1000 = e480000360
985694996 * 1000 = e580000620
% clock format 981400028
Mon Feb 05 20:07:08 GMT+01:00 2001
% clock format 985694996
Tue Mar 27 14:09:56 GMT+02:00 2001
Looking at your figures for the un-corrected and corrected versions of
Jacl:
Decimal Hexadecimal
1465268512 = 0xe4575f2648
980718397 * 1000 = 0x575f2648
shows us that your Linux figures are as wrong as any other "file mtime"
result and it shows why: Your time stamps were the same and the wrong one
had its left "0xe4" cut off.
My test run, described above, tells us that when running in certain time
slots, the result is wrong. Does a regression test of Jacl include
manipulating the system clock? If so, the shift at 2001-02-05 20:07:08 is a
good point in time to prove that the wrong version produces a wrong result
and that the result even can turn negative.
But when it comes to a straight test case, I give up.
Kind regards, Christian Sorensen
|
