Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!YALE.ARPA!fischer-michael From: fischer-michael@YALE.ARPA.UUCP Newsgroups: comp.sys.atari.st Subject: SETTIME bug Message-ID: <8702171647.AA04098@yale-eli.YALE.ARPA> Date: Tue, 17-Feb-87 11:47:48 EST Article-I.D.: yale-eli.8702171647.AA04098 Posted: Tue Feb 17 11:47:48 1987 Date-Received: Wed, 18-Feb-87 06:09:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 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 -------