+ A symptom of the same underlying problem, reported by Tony Martinez:
+ * (handler-case
+ (with-input-from-string (*query-io* " no")
+ (yes-or-no-p))
+ (simple-type-error () 'error))
+ ; in: LAMBDA NIL
+ ; (SB-KERNEL:FLOAT-WAIT)
+ ;
+ ; note: deleting unreachable code
+ ; compilation unit finished
+ ; printed 1 note
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
+ (from tonyms on #lisp IRC 2003-02-25)
+ In sbcl-0.7.12.55, typing
+ (defclass foo () ((bar :accessor foo-bar)))
+ (profile foo-bar)
+ (unintern 'foo-bar)
+ (defclass foo () ((bar :accessor foo-bar)))
+ gives the error message
+ "#:FOO-BAR already names an ordinary function or a macro."
+ So it's somehow checking the uninterned old accessor name instead
+ of the new requested accessor name, which seems broken to me (WHN).
+
+242: "WRITE-SEQUENCE suboptimality"
+ (observed from clx performance)
+ In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
+ (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+ (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+ rather than writing the sequence in one go, leading to severe
+ performance degradation.
+
+243: "STYLE-WARNING overenthusiasm for unused variables"
+ (observed from clx compilation)
+ In sbcl-0.7.14, in the presence of the macros
+ (DEFMACRO FOO (X) `(BAR ,X))
+ (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
+ somewhat surprising style warnings are emitted for
+ (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
+ ; in: LAMBDA (Y)
+ ; (LAMBDA (Y) (FOO Y))
+ ;
+ ; caught STYLE-WARNING:
+ ; The variable Y is defined but never used.
+
+244: "optimizing away tests for &KEY args of type declared in DEFKNOWN"
+ (caught by clocc-ansi-test :EXCEPSIT-LEGACY-1050)
+ In sbcl-0.pre8.44, (OPEN "foo" :DIRECTION :INPUT :EXTERNAL-FORMAT 'FOO)
+ succeeds with no error (ignoring the bogus :EXTERNAL-FORMAT argument)
+ apparently because the test is optimized away. The problem doesn't
+ exist in sbcl-0.pre8.19. Deleting the (MEMBER :DEFAULT) declaration
+ for :EXTERNAL-FORMAT in DEFKNOWN OPEN (and LOAD) is a workaround for
+ the problem (and should be removed when the problem is fixed).
+
+245: bugs in disassembler
+ a. On X86 an immediate operand for IMUL is printed incorrectly.
+ b. On X86 operand size prefix is not recognized.
+
+246: "NTH-VALUE scaling problem"
+ NTH-VALUE's current implementation for constant integers scales in
+ compile-time as O(n^4), as indeed must the optional dispatch
+ mechanism on which it is implemented. While it is unlikely to
+ matter in real user code, it's still unpleasant to observe that
+ (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours
+ to compile.
+
+248: "reporting errors in type specifier syntax"
+ (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
+ specifier".