fischer-michael@YALE.ARPA.UUCP (02/17/87)
The SETTIME program posted some time ago by Allan Pratt has a subtle
bug: When the time is 4:00PM or later, the GEMDOS clock is set correctly
but the IKBD clock is set one day too early. Then on each subsequent
reboot, the GEMDOS clock ends up one day off.
Since Allan was kind enough to post the sources, I was able to track down
the problem. Setting the IKBD clock requires packing two int's into a
longword. SETTIME did it as follows:
((long)date << 16) + time
(where in the actual code, "date" and "time" are really calls on the
GEMDOS functions Tgetdate and Tgettime, respectively). Unfortunately,
if the high-order bit of time is 1, C will sign-extend time when it
converts it to a long integer prior to performing the addition, with
the result that -1 is added to the date. A fix is to change this code
as follows:
((long)date << 16) + ((long)time & 0xffff)
One other thing I noticed that may or may not be a bug: SETTIME
assumes that the basepage contains a valid argument string with a
count in the range 0..127. If the number it picks up is not in this
range, it will randomly clobber memory. I don't know whether that
is a safe assumption or not.
I would be happy to repost the corrected source and .PRG files, but
they are copyrighted by Atari, so I do not think I should do so without
explicit permission of Atari. Perhaps Allan would prefer to make these
changes himself and repost the results.
--Mike Ficher <fischer@yale.arpa>
-------silvert@dalcs.UUCP (02/21/87)
In article <8702171647.AA04098@yale-eli.YALE.ARPA> fischer-michael@YALE.ARPA.UUCP writes: >The SETTIME program posted some time ago by Allan Pratt has a subtle >bug: When the time is 4:00PM or later, the GEMDOS clock is set correctly >but the IKBD clock is set one day too early. Then on each subsequent >reboot, the GEMDOS clock ends up one day off. Aha -- this explains a problem I've noticed with Braner's AUTODISK, which I think uses Pratt's code for setting the date -- I frequently note that the date ends up as yesterday, but I've never been sure when or how it happened, so I haven't mailed a bug report to Moshe. Is this really the cause? If so, Moshe, can you fix it? -- Bill Silvert Marine Ecology Laboratory, Dartmouth, NS, Canada CDN or BITNET: silvert@cs.dal.cdn -- UUCP: ..!{seismo|utai}!dalcs!silvert ARPA: silvert%dalcs.uucp@seismo.CSS.GOV -- CSNET: silvert%cs.dal.cdn@ubc.csnet