[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
.5LOCKI and a bug by JLS
- To: GLS at MIT-MC
- Subject: .5LOCKI and a bug by JLS
- From: JONL at MIT-MC (Jon L White)
- Date: Sun, 15 Jul 79 12:45:00 GMT
- Cc: (BUG LISP) at MIT-MC, jls at MIT-AI
- Original-date: 15 JUL 1979 0845-EDT
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.
Date: Sun, 18 Jun 79 19:29:02 GMT
Original-Date: 06/18/79 15:29:02 EDT
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)))
(SSTATUS TTYINT 6 '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
;JK UNBOUND VARIABLE
CAN YOU TELL ME WHY HJK IS SPLIT UP INTO TWO ATOMS.
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.