Return to my Computer pages
Go to my home page
© Copyright 1997, Jim Loy
Bugs are mistakes in a computer program. They are sometimes hard to find. They are especially hard to find, when they are not in the program that you are debugging, but in the compiler (like C++) or interpreter (like BASIC) or operating system (like MSDOS or Windows) that is running your program. Here are a few bugs that I remember.
The old Apple ][ computer was based on the 6502 chip. Apparently, there originally was a bug in the chip. Memory addresses took 2 bytes to describe them, a "page" number and the actual one byte address within that page. In assembly language, some commands which were three bytes long had an address as the last two bytes. If the third byte of these commands was in the next page of memory from the other two bytes, then the computer would misread this byte (getting it from the beginning of the same page of memory). That is fairly esoteric. But imagine trying to debug such a situation. Maybe you have just added one character to a comment line to a program which used to work just fine. And now your program misbehaves at an entirely different place in the program. It jumps, seemingly at random, to the wrong place in the program. It would run just fine when you add a few control pauses to the program. You could spend weeks debugging your program, and never figure it out.
In COBOL, one error (failing to declare a variable name, usually) could cause hundreds of error messages, at compile time. I might have bragged that I had over 200 error messages, and cleared it up with a one character change to the program. COBOL is often ridiculed, as an extremely awkward and wordy language (SUBTRACT MONEYAMOUNT FROM OTHERMONEYAMOUNT GIVING DIFFERENCEAMOUNT is an example). But it was, in general, a very fast and efficient compiler.
In old versions of FORTRAN, another fast compiler, dealing with an array was sometimes tricky. J(3*I+5)=10 was legal, while J(5+I*3) was illegal. The index to the array had to be constant*variable±constant, or something simpler. Also, you could accidentally go beyond the bounds of the array, with no error message, something that is possible in some compilers today.
In some BASICs (and FORTRANs too), you could choose unfortunate variable names, like FORTY=40, which was a syntax error, since FOR is the beginning of a FOR/NEXT loop. That statement would look like FOR TY=40 to the BASIC interpreter, and is missing the TO... portion of the statement. Once I got used to this kind of error, the syntax error messages were usually the only clue that I needed, in order to figure things out. A friend of mine told me that FORK=1 TON, which was a valid FOR statement.
There was once an IBM BASIC which sometimes said "Syntax error" when it should have said "Out of memory." It would tell you the line number of the error. And you could verify that that line was not a syntax error, over and over again. Testing showed that we could make the "Syntax error" message appear and disappear, just by changing the size of some arrays. But, it caused hours of work.
In an old version of CBASIC, -0 was not equal to +0. This actually took days to discover. And eventually, our programs (dealing only with integers) became littered with statements like: IF -1*A=0 THEN A=0. The statement IF A=-0 THEN A=0 did not work, by the way, as the A=-0 came out true, only when A=+0. -1*A was an arithmetic expression which was evaluated at run time, while -0 was evaluated as +0 at "compile" time. CBASIC was something like a compiler.
In ITT BASIC, a version of Microsoft BASIC, the SPACE$() function, which produced a string of spaces, of whatever length you wanted, had a minor bug. It took a long time (a second or so) to execute. This was no problem, in general. But, when the SPACE$() function was within a loop, like when I wanted to initialize a string array, the program would appear to be in an infinite loop. It would just sit there. That took a while to figure out.
dBase 2 would reindex your file, every time you changed a field in a record, even if the field was not part of the index key. This slowed down programs tremendously. So, Ashton Tate added a NOUPDATE option to some of the commands. With this option, you could force dBase to not update the index file.
At one time dBase (when Ashton Tate owned it) had a bug in its text editor (with which you edited programs). I would add a few lines to a program, and exit the editor, and a little message would sometimes appear saying "out of memory." This message was not accompanied by a beep, and all I had to do to continue was to press the ENTER key, and several lines from the end of my program would disappear. This happened to me, many many times. Ashton Tate's initial solution to this was to allow you to use the text editor of your choice, instead of theirs.
At that time, dBase data files often got trashed. Any program which uses several related files simultaneously (data files and index files in dBase), will sometimes have files that no longer match. So records seem to disappear. Well, sometimes the index file did not match the data file, usually because of a program crash because of an unrelated bug. And then if you later opened the data file and index file again, massive damage would often happen to the data file (Ashton Tate blamed MSDOS for this). So, recovering damaged dBase files became a major part of my job. And some of my programs had to check to see if any other program had recently terminated with files still open. Then the program would rebuild those index files from scratch, as opening the index file (in order to use the REINDEX command) might error out.
In the Sorting And Searching volume of Knuth's classic The Art Of Programming, the algorithm for Quicksort has three bugs in it. I translated the algorithm into BASIC, and then spent hours debugging it. The algorithm was hard to debug, at first, as Quicksort had another sort built into it. So, even though the Quicksort part didn't sort, my list always ended up sorted. However, those were hours very well spent. I learned a lot, by studying Quicksort. Knuth certainly did not put those bugs in there intentionally. But, they were very helpful to me. Sometimes you actually have to understand what you are doing.
Compilers and operating systems are very complicated, now more than ever. And they will continue to have bugs.