Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!lynx.northeastern.edu!davidbrierley From: davidbrierley@lynx.northeastern.edu Newsgroups: comp.sys.apple Subject: Re: Applesoft Bugs Message-ID: Date: 15 Jan 90 19:49:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 72 Here's some info from various sources on Applesoft bugs: ONERR bugs Certain combinations of errors will cause the machine to lock up or crash if an ONERR statement is active. The cure for some of these problems is to add these lines to the BASIC program and use a CALL 768 at the beginning of an error-handling routine: 60 DATA 104,168,104,166,223,154,72,152,72,96 70 FOR ML = 768 TO 777: READ MC: POKE ML,MC: NEXT ML (Source: _Apple II User's Guide_, 3rd ed. Lon Poole 1985 pp. 276-277) Leaving an error-handling routine with a GOTO statement (instead of a RESUME statement) doesn't clear information from an internal control stack, causing the machine to crash in some cases. The solution for this is to use the RESUME statement or to use a CALL -3288 before leaving the routine with a GOTO statement. (Source: _Applesoft BASIC Programmers Reference Manual_, 1987 p. 65) ------------------------------------------------------------------------------ VAL bug Program example: 10 A$="1E99":REM DISAPPEARING REMARK 20 PRINT VAL(A$) When run, an overflow error occurs. When listed, the REM statement and the accompanying message disappear. The line looks like: 10 A$="1E99 The error causes VAL to give up evaluating the argument, without restoring the closing quote - which is normally temporarily replaced by a zero byte to signify the end of the string. The only cure appears to be to avoid overflows and keep string assignments at the end of program lines or in lines by th y themselves. (Source: Compute's Apple Applications, June, 1988. (Vol. 6, No. 3) p. 63) Note: Compute's Apple Applications is now a defunct magazine. ------------------------------------------------------------------------------- INT bug Program example: 10 A = 1 / 7: B = 0 20 FOR I = 1 TO 14 30 B = B + A 40 NEXT I 50 PRINT INT (B) The resulting answer is 1 instead of two. One suggestion was to add a very small constant (.000001) to the variable just before using INT; however it may produce an inaccurate result in some cases. The other suggestion was to use the STR$ function: 50 PRINT INT( VAL ( STR$ (B))) The problem here is that the STR$ function is slower. (Source: Compute's Apple Applications, February 1988, (Vol. 6, No. 1) p. 76) ---------------------------------------------------------------------------- Please note that the above are not quotations from the sources. The February, 1988, issue of CAA also describes other errors with the TRACE command, CHAIN, and the loss of data when accessing locked text files. These errors will need more or less verbatim discussion so I'll e-mail the article to anyone who sends e-mail to me with the subject BUGS. David R. Brierley davidbrierley@lynx.northeastern.edu