Hi,
*read-eval* is currently set to T everywhere something is READ. While I don't currently see anything that could be (at least easily) exploitable, it still leaves an uneasy feeling in my stomach. Especially in the present of things like autodoc.
Therefore I propose the following:
(i) Setting *READ-EVAL* to NIL in CALL-WITH-BUFFER-SYNTAX.
(ii) Introducing a new macro WITH-SAVE-IO-SYNTAX that expands to (WITH-STANDARD-IO-SYNTAX (LET ((*READ-EVAL* NIL)) ...)) and replacing all occurences of WITH-STANDARD-IO-SYNTAX with this new macro.
Any thoughts on this issue?
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
*read-eval* is currently set to T everywhere something is READ. While I don't currently see anything that could be (at least easily) exploitable, it still leaves an uneasy feeling in my stomach. Especially in the present of things like autodoc.
As I explained before, we cannot use READ in the context of autodoc anyway because of interning.
The use of READ on protocol messages is safe because these messages, as constructed by SLIME, do not contain any "#." It would not hurt though to bind *read-eval* = nil while reading these messages. You don't need a new or changed macro for that.
As far as I know, all other cases where READ is used on Lisp program text that comes from some Emacs buffer, the user has explicitly requested the evaluation or compilation of some code, and we don't want to refuse to evaluate code that depends on *read-eval* = t.
Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
As I explained before, we cannot use READ in the context of autodoc anyway because of interning.
I just committed my changes to remedy the interning. It does still fall back to READ. The benefit is that this also fixes interning for `slime-complete-form' at once --- which until now always interned everything.
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
As I explained before, we cannot use READ in the context of autodoc anyway because of interning.
I just committed my changes to remedy the interning. It does still fall back to READ. The benefit is that this also fixes interning for `slime-complete-form' at once --- which until now always interned everything.
The solution in the new version of READ-FORM-SPEC is not sufficient, because it does not handle symbols interned in nested forms.
I type:
(defmethod (tyy zzz) abcd ...
now (SWANK::READ-FORM-SPEC ("(tyy zzz)")) gets called, and returns values ((TYY ZZZ)) NIL.
Now:
(find-symbol "TYY") TYY :INTERNAL
In general the "destroy-and-repair" (here: "intern-and-unintern") method is not giving a clean implementation.
As I said, you simply cannot use READ in the context of autodoc.
What you need to do -- if you want to use your proposed protocol of sending forms to SWANK -- is implement a limited reader in READ-FORM-SPEC. It only needs to handle lists, numbers, strings, and symbols to be useful in this context. It should never intern symbols and gracefully handle what would be a reader error for READ. It should not be very hard to write; give it a try.
Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
The solution in the new version of READ-FORM-SPEC is not sufficient, because it does not handle symbols interned in nested forms. [(defmethod (tyy zzz) abcd ...]
Yeah, that was a bug.
In general the "destroy-and-repair" (here: "intern-and-unintern") method is not giving a clean implementation.
I agree that it's not very clean. But it seems to be an acceptable tradeoff to me:
The code now only hard-interns on very obscure occasions (or so I hope!), and should not do so any more than of before my changes on the same instances. And the code does actually deal with `C-c C-s' -- which, as I mentioned already, interned everything previously. And I personally use C-c C-s much more often than stumbling over one of those obscure occasions.
What you need to do -- if you want to use your proposed protocol of sending forms to SWANK -- is implement a limited reader in
(I'm open for suggestions to improve the protocol. I just tried to keep it as simple and as flexible as possible.)
READ-FORM-SPEC. It only needs to handle lists, numbers, strings, and symbols to be useful in this context. It should never intern symbols and gracefully handle what would be a reader error for READ. It should not be very hard to write; give it a try.
I've thought about that before, but how is this supposed to work with `slime-complete-form' without reimplementing a whole reader?
-T.
There's currently a bug I've tried the whole day to track down, but I've not been able to so far:
If you have `(defmethod foo args...)', and have point say at `args', then press C-f, the arglist is displayed endlessly (as can be witnessed if you look into *Messages*.) You may need a bit of experimentation to reproduce it.
I'm perplexed what this could be. (I haven't touched the autodoc caching stuff, and from debugging it seems to work.) I know that it's been introduced by my recent changes, and that it does only occur when tried on one of the specially parsed operators.
Kudos, if you've got an idea, it'd be awesome!
"Tobias C. Rittweiler" tcr@freebits.de writes:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
The solution in the new version of READ-FORM-SPEC is not sufficient, because it does not handle symbols interned in nested forms. [(defmethod (tyy zzz) abcd ...]
Yeah, that was a bug.
In general the "destroy-and-repair" (here: "intern-and-unintern") method is not giving a clean implementation.
I agree that it's not very clean. But it seems to be an acceptable tradeoff to me:
I do not agree, see below.
The code now only hard-interns on very obscure occasions (or so I hope!), and should not do so any more than of before my changes on the same instances.
My old code worked perfectly, it never interned anything on autodoc.
This is an essential, non-negotiable requirement, as it is invoked automatically, on pretty arbitrary stuff from buffers that is gathered by some heuristic on the Emacs side.
I do not accept replacing this by something that works "most of the time".
You simply cannot control the interning behavior of READ. Look what happens when a reader error occurs somewhere. You have no control over what symbols it has already interned when the error is signalled.
I type:
(defmethod (foo #Q)
Now:
(find-symbol "FOO") FOO :INTERNAL
And the code does actually deal with `C-c C-s' -- which, as I mentioned already, interned everything previously.
If we can achieve that, it would be great; but C-c C-s is explicitly user-invoked, so interning safety is not essential.
And I personally use C-c C-s much more often than stumbling over one of those obscure occasions.
The problem is one cannot know when the obscure occasions occur.
What you need to do -- if you want to use your proposed protocol of sending forms to SWANK -- is implement a limited reader in
(I'm open for suggestions to improve the protocol. I just tried to keep it as simple and as flexible as possible.)
I designed the old protocol (which just gathers the required information for every supported operator in a safe way) specifically to avoid READ. You either implement something like this again, or as an alternative you employ a safe restricted reader.
READ-FORM-SPEC. It only needs to handle lists, numbers, strings, and symbols to be useful in this context. It should never intern symbols and gracefully handle what would be a reader error for READ. It should not be very hard to write; give it a try.
I've thought about that before, but how is this supposed to work with `slime-complete-form' without reimplementing a whole reader?
You use the safe reader for autodoc, where safety is essential.
For slime-complete-form, you offer two modes, controlled by a user variable. One safe variant that cannot handle everything. One less-safe variant (using READ) that can handle everything.
There's currently a bug I've tried the whole day to track down,
Sorry, I don't have time to work on it. Check whether the cache works and whether there are equality issues.
Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
You simply cannot control the interning behavior of READ. Look what happens when a reader error occurs somewhere. You have no control over what symbols it has already interned when the error is signalled.
That one's trivial to fix. Forgot an UNWIND-PROTECT at the right place.
And I personally use C-c C-s much more often than stumbling over one of those obscure occasions.
The problem is one cannot know when the obscure occasions occur.
One can. It's only possible in extended operator parsing. And there specifially just that which `slime-make-form-spec-from-string' lets through.
(I'm open for suggestions to improve the protocol. I just tried to keep it as simple and as flexible as possible.)
I designed the old protocol (which just gathers the required information for every supported operator in a safe way) specifically to avoid READ.
Yeah, that's because previously only straightforward information was required.
You either implement something like this again, or as an alternative you employ a safe restricted reader.
The problem with the own reader is that this one should probably also understand unicode if the lisp implementation underneath does so, too. I'm not sure how smoothly this can be done then.
So I'll probably cut some of the flexibility.
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
There's currently a bug I've tried the whole day to track down, but I've not been able to so far:
If you have `(defmethod foo args...)', and have point say at `args', then press C-f, the arglist is displayed endlessly (as can be witnessed if you look into *Messages*.) You may need a bit of experimentation to reproduce it.
I'm perplexed what this could be.
I think something, in the extended operator parsing probably, is setting the mark---causing "Mark set" to be messaged over and over again, causing the arglist to be redisplayed each time (which, as it seems, causes the "Mark set" message to be sent again, and so on...)
-T.
On 8/26/07, Tobias C. Rittweiler tcr@freebits.de wrote:
Any thoughts on this issue?
As long as the following continue working, I'm happy:
#. in my source buffers should not stop evaluation and compilation commands from working.
Objects printing using #. syntax should not break anything.
If either of these stops working, That Would Be Bad.
Cheers,
-- Nikodemus
-
Matthias Koeppe -
Nikodemus Siivola -
Tobias C. Rittweiler