Re: [tcljava-dev] Jacl and file mtime
Brought to you by:
mdejong
|
From: Mo D. <md...@cy...> - 2001-01-28 22:51:15
|
On Tue, 9 Jan 2001 cs...@ma... wrote:
> Hi again!
>
> Re: tcljava-dev digest, Vol 1 #14.
>
> I have made a test case, modifying the FileCmd.test element "filecmd-17.2"
> into this:
>
> test filecmd-17.2 {cmdProc: mtime} {
> set old [file mtime gorp.file]
> for {set i 0} {$i < 10000} {incr i} {
> }
> set f [open gorp.file w]
> puts $f "More text"
> close $f
> set new [file mtime gorp.file]
> puts "old / new: $old / $new"
> #expr {($new > $old) && ($new <= ($old+5))}
> expr {($new > $old)}
> } {1}
>
> Provided that there is a file called "gorp.file" when you start, the test
> will run. The "puts old/new..." statement shows something like:
>
> old / new: 979032853 / 979032903
>
> when running with the patch, and something like:
>
> old / new: -219219228 / -219202955
>
> on the orignal Jacl 1.2.6. The annoying part is that the wrong results
> actually gave the rigth answer - the second number is greater than the
> first. The experiences leading me to finding this error, however, showed me
> that this answer could easily be the other way around. Anyway, a negative
> number can never be what we want.
>
> Kind regards, Christian Sorensen.
Sorry, but I just don't see how your test
case demonstrates the problem you talked
about. It seems like you just added
a for loop to the original filecmd-17.2
test. I don't get it.
When I run the test case with Jacl
from the current CVS, I get the
following on Linux:
old / new: 1465268512 / 1465270512
With your patch, I see results
more like:
old / new: 980718397 / 980718399
You were reporting results like:
> old / new: -219219228 / -219202955
I have to assume that this only happens
on Windows. Is the problem just that
these numbers are less than zero? Could
you just change the test case so
that it made sure both of the
numbers that were returned were
greater than zero?
Mo DeJong
Red Hat Inc
|