Jeremy Brown <jhbrown@...> writes:
> Ah, thank you very much. Since bug report 281 is gone from the BUGS
> file, I assume I don't need to worry about the problem where "setting
> it to a non-NIL value is likely to render the system vulnerable to a
> carefully crafted test along the lines of that report" mentioned here?
For reference, here's the old bug:
281: COMPUTE-EFFECTIVE-METHOD error signalling.
(slightly obscured by a non-0 default value for
It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
when it finds a method with invalid qualifiers. However, it
shouldn't signal errors when any such methods are not applicable to
the particular call being evaluated, and certainly it shouldn't when
simply precomputing effective methods that may never be called.
(setf sb-pcl::*max-emf-precompute-methods* 0)
(defgeneric foo (x)
(:method ((x symbol)) 1)
(:method + ((x number)) x))
(foo 1) -> ERROR, but should simply return 1
The issue seems to be that construction of a discriminating function
calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
The fix in this case was:
0.9.0.27: fix bug 281, plus a tiny PCL cleanup
* COMPUTE-EFFECTIVE-METHOD-COMBINATION for SHORT-METHOD-COMBINATION should
not signal an error for a bogus qualifier, but merely return a form that
takes care of the signalling later.
* EWTF: ESETF cannot be an optimization anymore, if it ever was.
What does this mean?
I _think_ it means you don't have to worry, but since the normal value
for *max-emf-precomputation-methods* is NIL, there may well be other
code-paths in which similar suprises lurk.
So, my suggestion is to set the variable with impunity, and report any
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."