daveh@marob.masa.com (Dave Hammond) (10/06/89)
System: 386 compatible, SCO Xenix 2.3.1
Compiler: Microsoft (standard SCO 'cc').
A program I am working on appears to have stepped into a time warp!
Time() is returning values from 2 different clocks -- the current time
and a time which appears off by about 20 years.
The clock appears to flip-flop based upon the return stack depth.
Time() will return valid data in main() and in routines called directly
from main(), but not in routines called from main() subroutines.
I have looked into the obvious things. The argument passed to time() is
always a valid long integer address {long t, time(); t = time(&t);}. It
does not matter if the variable declaration is external or auto, nor
whether auto variables are declared on entry to a routine or within a
subsequent block. In fact, the argument to time() probably does not
enter into the picture, because passing a null argument has the same
effect.
I have noticed a few peculiarities: BOTH the correct and bogus times
increment normally; time() always thinks it did the right thing (-1 is
never returned and errno never set); while the bogus time appears to
represent a future date, ctime() converts it a past date, prior to the
documented zero time (Jan 1. 1970 GMT).
The following edited script traces the situation described above. MAIN
prefixes lines generated in main(), SUB1 prefixes lines generated in
main() subroutines, and SUB2 prefixes those generated in deeper
subroutines.
Script started [typescript] at Thu Oct 5 15:05:46 1989
$ ./ma tt.m >/dev/null
MAIN:entry: tim=623617560, errno=0, ctim=Thu Oct 5 15:06:00 1989
SUB2:exe entry: tim=4294944268, errno=0, ctim=Wed Dec 31 12:36:12 1969
MAIN:init: tim=623617563, errno=0, ctim=Thu Oct 5 15:06:03 1989
MAIN:source: tim=623617563, errno=0, ctim=Thu Oct 5 15:06:03 1989
[top of loop]
SUB1:loop: tim=623617564, errno=0, ctim=Thu Oct 5 15:06:04 1989
[the nexet 2 lines are generated by the last statement in the SUB1
function before calling SUB2 and the first statement in SUB2 after
variable declarations.]
SUB1:call mr: tim=623617564, errno=0, ctim=Thu Oct 5 15:06:04 1989
SUB2:mr entry: tim=4294944284, ctim=Wed Dec 31 12:36:28 1969
SUB2:call mnu: tim=4294944286, ctim=Wed Dec 31 12:36:30 1969
SUB1:call exe: tim=623617566, errno=0, ctim=Thu Oct 5 15:06:06 1989
SUB2:exe entry: tim=4294944286, errno=0, ctim=Wed Dec 31 12:36:30 1969
[repeat loop]
SUB1:loop: tim=623617567, errno=0, ctim=Thu Oct 5 15:06:07 1989
SUB1:call mr: tim=623617567, errno=0, ctim=Thu Oct 5 15:06:07 1989
SUB2:mr entry: tim=4294944287, ctim=Wed Dec 31 12:36:31 1969
SUB2:call mnu: tim=4294944288, ctim=Wed Dec 31 12:36:32 1969
SUB1:call exe: tim=623617568, errno=0, ctim=Thu Oct 5 15:06:08 1989
SUB2:exe entry: tim=4294944288, errno=0, ctim=Wed Dec 31 12:36:32 1969
[repeat loop]
SUB1:loop: tim=623617568, errno=0, ctim=Thu Oct 5 15:06:08 1989
SUB1:call mr: tim=623617569, errno=0, ctim=Thu Oct 5 15:06:09 1989
SUB2:mr entry: tim=4294944289, ctim=Wed Dec 31 12:36:33 1969
SUB2:call mnu: tim=4294944292, ctim=Wed Dec 31 12:36:36 1969
SUB1:call exe: tim=623617572, errno=0, ctim=Thu Oct 5 15:06:12 1989
SUB2:exe entry: tim=4294944292, errno=0, ctim=Wed Dec 31 12:36:36 1969
[end of script]
While I'm sure this is due to some SLB (steenkin' little bug :-), I
can't imagine what would have to be broken to make the program exhibit
this behavior. It exhibits no other *obvious* bugs or side-effects.
Suggestions as to probable causes, possible solutions or obvious idiocy
would be greatly appreciated.
--
Dave Hammond
daveh@marob.masa.comcpcahil@virtech.UUCP (Conor P. Cahill) (10/06/89)
In article <252BFD80.194C@marob.masa.com>, daveh@marob.masa.com (Dave Hammond) writes: > System: 386 compatible, SCO Xenix 2.3.1 > Compiler: Microsoft (standard SCO 'cc'). Is this Xenix for a 386 or for a 286? This could matter. time(2) is a system call that in the kernel does not take an argument. The system call library interface routine simply stores the return value in the argument if the argument is non-null. Therefore time(2) should return the same (allowing for ongoing second incrementation) reguardless of the calling context. This would seem to indicate that there is a problem in your code which I cannot comment on since you did not post it. You should try to put together the smallest section of code that will replicate your problem and post it. My totally ignorant *guess* would be that you are overrunning some variable on your stack. This could cause the problem you are seeing (even with the second incrementing you are seeing) because of the way that the 80386 stores integers (in reverse byte order). For example: long t = 0x01020304; in memory: 0x04 0x03 0x02 0x01 so the 0x02,0x01 could be getting messed up and they will still seem correct. This would also be a symptom if you are storing the result of the time(2) system call into a short integer. - Yes, I know you said that you are doing it right, but I can't see it so I am just running off a list of possible explanations. As to ctime() returning < Jan 1, 1970, this is due to your time being a negative number. On System V.3, time_t is defined as a (signed) long and therefore 4294944287 unsigned is equal to -23009 signed. The additional hours before Jan 1, 1970 is due to the timezone difference from GMT. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+