[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Dick at MIT-MC
- From: Ed Barton <EB at MIT-OZ>
- Date: Thu, 4 Nov 82 21:46:00 GMT
- Cc: bug-maclisp at MIT-OZ, EB at MIT-OZ
- Original-date: 4 Nov 1982 1646-EST
Date: Thursday, 4 November 1982 14:28-EST
Sender: DICK at MIT-OZ
To: bug-maclisp at MIT-OZ
On the 20 (i.e. OZ) both lisp and the complr open their files in a
restricted mode that makes it impossible for anything else to touch
the files. For example, the exec won't even show that they exist or
Most of the time this dosn't matter, but consider the following situation.
The compiler dies in a strange state, and you are trying to figure out what
is going on. Under ITS you could always go into ddt and look at the _unfa_
file in order to get some idea about what was going on. On OZ you cannot
do that becuase though the file is there, it is restricted and you cannot
touch it. In particular, you cannot close it, so when the complr fork
is killed, the file is automatically deleted.
It seems to me that things would be a great deal more convenient if
lisp in general and the complr in particular just opened files normally.
Does nobody fix LISP bugs? I sent numerous bug reports about this
years ago and the response from JONL was that LISP didn't do what LISP
in fact does, that is, open the JFN in restricted mode. Then a few
months later someone (on the west coast, I believe) ran into the same
problem and got the same response, but tracked down the place IN THE
CODE where LISP was opening its JFNs in restricted mode. Now it seems
to me that once the offending piece of code has been identified, that is
sufficient both to prove that LISP is guilty of this paranoid behavior
and to show the implementors how to fix it. But No.... I just opened
a file with Lisp on OZ and its JFN didn't even show up in the exec's
@i files printout. SYSDPY told me it was there, though, assigned in
restricted mode just like the old bug.