.5LOCKI and a bug by JLS

[JONL at MIT-MC (Jon L White)]

I presume you wrote the greater part of the code for 
$DEVICE - maybe you could comment on this analysis:
There are two places which could invert the order of
two characters typed in at the tty:
1) the .5locki permits some interrupts durint the i/o wait
   for the tty, and indeed during the whole routine.  one
   such interrupt could, sub-recursively, call read etc. and
   cause some chars to be "buffered-back".  
2) the CALL to the tty-buffering routine (rubout processor) is
   done after doing UNLOCKI.  thus during the time in which it
   runs up to the point wherein the list of returned chars is
   smashed into the FI.BBC slot of the tty file array, there
   could be an interrupt which could, sub-recursively, call read
   etc. and cause some chars to be "buffered-back".
In the first case, the first "buffered-back" char will be
interchanged in time sequence with the char which was currently
being read by the .IOT (or whatever);  in the second, all such
"buffered-back" chars are lost due to the smashing action.

I believe this explains the following bug, found by Stansfield,
and also believe I have (gleep with many instructions) patched it.

From:     JLS@MIT-AI
Date: Sun, 18 Jun 79 19:29:02 GMT
Original-Date: 06/18/79 15:29:02 EDT
Subject:
    HI,
        I FOUND SOME STRANGE BEHAVIOR IN LISP. THE FOLLOWING IS
    THE TYPE-IN AND TYPE-OUT AS IT APPEARED ON THE SCREEN. IT
    SEEMS THAT THE FUNCTION TO CONSTRUCT ATOMS FROM INPUT GETS
    CONFUSED AND PUTS IN A DELIMITER WHERE THERE IS NONE.


    (DEFUN FOO (X Y) (PRINT (TYI)) (PRINT (READ)))
    FOO
    (SSTATUS TTYINT 6 'FOO)
    FOO

    BAR<SPACE>       ;; I TYPE IN CONTROL-F "BAR" AND <SPACE>
    6                  ;; FOO ECHOES CONTROL-F
    BAR HJK<SPACE>     ;; FOO ECHOES BAR. I TYPE <SPACE>HJK<SPACE>

    ;H UNBOUND VARIABLE

    ;BKPT UNBND-VRBL
     
    ;JK UNBOUND VARIABLE


         CAN YOU TELL ME WHY HJK IS SPLIT UP INTO TWO ATOMS.

             JIM STANSFIELD

I also wonder if there have been any other bug-lisps
reported which this corrects - it still doesn't take 
care of the case of a pseudo-space being inserted at the end
of some toplevel symbols.