...and the other one

The second bug is harder to spot, since for most of test inputs our program will work correctly. This is a typical example of a program broken for boundary conditions. To make it easier to track the problem set MAXLIN to some small integer (around 10 should be good), recompile the program, restart the debugging session and set a breakpoint at main+28, just after a character was read. Set this breakpoint with a count and a request to show a received character with

main+28,5:b <d0=cx
With carefuly chosen input this will show where you are in the program and will skip unnecessary stops in the same time. You have to provide an input by typing it yourself. Remember that to repeat the last command :c it is enough to hit 〈Return〉. For execution defaults szadb will use the most recently typed command even if some other requests were executed by breakpoints.

In order to see how the received character is processed you can single step with :s, which will follow program execution. The request :n will single step like :s but will execute function calls at full speed and so have the effect of stepping over them. Breakpoints set on skipped levels still will be obeyed.

Tracing some tests inputs with the value of the variable col around MAXLIN should reveal the second error soon enough. If you want to try it yourself, do not read further.

Looking at line 17 we find a sharp less-than inequality in the test. It should be replaced by a less-than-equal-to. Otherwise, when the value of col equals MAXLIN, and your input is "right", the program is trying to read, in lines 28 and 31, from the location &tabs[col], which is one past the end of the array. The remaining analysis of this bug is left as an exercise to the reader.