CompuServe Thread

Recently a customer informed me of problem he was having with his TRS-80 Model 100. We constructed a five line BASIC program that demonstrated the bug: 10 CLEAR 256,MAXRAM 20 A$="This is a "+"string." 30 PRINT A$ 40 PRINT FRE$("") 50 PRINT A$ The expression in 20 forces A$'s contents to be placed in the string buffering area. The FRE("") in 40 forces compression of the buffer and prints the number of free bytes in it. Between the end of 30 and 50 the value of A$ has changed from "This is a string." to "……………..". After investigating the machine code that handles the BASIC commands in this program I discovered that the bug actually occurs during 10. When the BASIC CLEAR command has a second argument AND the first string that was placed in the buffer has not be redefined by the time compression occurs, all characters in strings whose contents reside in the buffer will be redefined as the last character in that first string. Fortunately, there is a simple measure to prevent this bug from getting into your program. Immediately follow any CLEAR that assigns HIMEM by a CLEAR without any arguments. Hence, to fix the above program change 10 to: 10 CLEAR 256,MAXRAM:CLEAR It is important to realize that even if HIMEM is unchanged by the statement "CLEAR 256,<value>" that this bug may occur. You might still be wondering why you haven't seen this problem. It seems like it would show up often. Its rarity is explained by the second requirement: the first string that was placed in the buffer must not have been redefined before compression. If this second condition is not met, compression will proceed smoothly and correctly. Few programs meet this condition, however, some programs may meet this condition in certain situations. Such programs may appear to work correctly when actually data corruption is just waiting for the proper sequence of events. WORDS TO THE WISE: If you use CLEAR with a second parameter follow it with a CLEAR. ..Tom Bennett (PEaC)