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 |