DTC's recommended workaround from the mailing list 3 Mar 2000:
(setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
-22:
- The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
- says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
- inside "~<..~>" (without the colon modifier on the closing syntax).
- However, SBCL doesn't do this:
- * (FORMAT T "~<munge~wegnum~>" 12)
- munge12egnum
- NIL
-
27:
Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
Process inferior-lisp exited abnormally with code 1
I haven't noticed a repeatable case of this yet.
-31:
- In some cases the compiler believes type declarations on array
- elements without checking them, e.g.
- (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1)))
- (DEFSTRUCT FOO A B)
- (DEFUN BAR (X)
- (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X))
- (WHEN (CONSP (AREF X 0))
- (PRINT (AREF X 0))))
- (BAR (VECTOR (MAKE-FOO :A 11 :B 12)))
- prints
- #S(FOO :A 11 :B 12)
- in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for
- all cases, e.g. the type assumption *is* checked if the array
- elements are declared to be of some structure type instead of CONS.
-
32:
The printer doesn't report closures very well. This is true in
CMU CL 18b as well:
MERGE also have the same problem.
c: (COERCE 'AND 'FUNCTION) returns something related to
(MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
- f: (FLOAT-RADIX 2/3) should signal an error instead of
- returning 2.
- g: (LOAD "*.lsp") should signal FILE-ERROR.
h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
should signal TYPE-ERROR.
i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
TYPE-ERROR when handed e.g. the results of
MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
the inappropriate positions, but doesn't.
- j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
- (QUOTE STRING)))
- should probably signal an error instead of making a pathname with
- a null byte in it.
k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
not a binary input stream, but instead cheerfully reads from
character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
but SBCL doesn't do this. (Also as reported by AL in the same
message, SBCL depended on this nonconforming behavior to build
itself, because of the way that **CURRENT-SEGMENT** was implemented.
- As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
+ As of sbcl-0.7.3.x, this dependence on the nonconforming behavior
has been fixed, but the nonconforming behavior remains.)
104:
Evidently Python thinks of the lambda as a code transformation so
much that it forgets that it's also an object.
-126:
- (fixed in 0.pre7.41)
-
127:
The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
specifies a precedence rule for name collisions between slot accessors of
still some functions named "hairy arg processor" and
"SB-INT:&MORE processor".
-140:
- (reported by Alexey Dejneka sbcl-devel 2002-01-03)
-
- SUBTYPEP does not work well with redefined classes:
- ---
- * (defclass a () ())
- #<STANDARD-CLASS A>
- * (defclass b () ())
- #<STANDARD-CLASS B>
- * (subtypep 'b 'a)
- NIL
- T
- * (defclass b (a) ())
- #<STANDARD-CLASS B>
- * (subtypep 'b 'a)
- T
- T
- * (defclass b () ())
- #<STANDARD-CLASS B>
-
- ;;; And now...
- * (subtypep 'b 'a)
- T
- T
-
- This is probably due to underzealous clearing of the type caches; a
- brute-force solution in that case would be to make a defclass expand
- into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
- but there may be a better solution.
-
141:
Pretty-printing nested backquotes doesn't work right, as
reported by Alexey Dejneka sbcl-devel 2002-01-13:
It should be possible to be much more specific (overflow, division
by zero, etc.) and of course the "How can this be?" should be fixable.
-147:
- (reported by Alexey Dejneka sbcl-devel 2002-01-28)
- Compiling a file containing
- (deftype digit () '(member #\1))
- (defun parse-num (string ind)
- (flet ((digs ()
- (let (old-index)
- (if (and (< ind ind)
- (typep (char string ind) 'digit))
- nil))))))
- in sbcl-0.7.1 causes the compiler to fail with
- internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
- This problem seems to have been introduced by the sbcl-0.pre7.* compiler
- changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
- test case is
- (defun parse-num (index)
- (let (num x)
- (flet ((digs ()
- (setq num index))
- (z ()
- (let ()
- (setq x nil))))
- (when (and (digs) (digs)) x))))
- In sbcl-0.7.1, this second test case failed with the same
- internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
- After the APD patches in sbcl-0.7.1.2 (new consistency check in
- TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
- new consistency check from failing routinely) this second test case
- failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
- closing over unreferenced variables) made this second test case
- compile without error, but the original test case still fails.
-
- Another way to get rid of the DEFTYPE without changing the symptom
- of the bug is
- (defvar *ch*)
- (defun parse-num (string ind)
- (flet ((digs ()
- (let ()
- (if (and (< ind ind)
- (sb-int:memq *ch* '(#\1)))
- nil))))))
- In sbcl-0.7.1.3, this fails with
- internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
- The problem occurs while the inline expansion of MEMQ,
- #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
- is being LET-converted after having its second REF deleted, leaving
- it with only one entry in LEAF-REFS.
-
148:
In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
(in-package :cl-user)
but it has happened in more complicated cases (which I haven't
figured out how to reproduce).
-155:
- (fixed in sbcl-0.7.2.9)
-
156:
FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
* (function-lambda-expression #'(lambda (x) x))
UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
(reported by Alexey Dejneka sbcl-devel 2002-04-12)
-158:
- Compiling the following code causes SBCL 0.7.2 to bug. This only
- happens with optimization enabled, and only when the loop variable is
- being incremented by more than 1.
- (defun foo (array)
- (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
- (loop for i from 0 to 10 by 2
- do (foo (svref array i))) (svref array (1+ i)))
- (reported by Eric Marsden sbcl-devel 2002-04-15)
-
162:
(reported by Robert E. Brown 2002-04-16)
When a function is called with too few arguments, causing the
isn't too surprising since there are many differences in stack
implementation and GC conservatism between the X86 and other ports.)
-163:
- HOST-NAMESTRING on a Unix pathname returns "Unix", which isn't
- treated as a valid host by anything else in the system. (Reported by
- Erik Naggum on comp.lang.lisp 2002-04-18)
-
-164:
- The type system still can't quite deal with all useful identities;
- for instance, as of sbcl-0.7.2.18, the type specifier '(and (real -1
- 7) (real 4 8)) is a HAIRY-TYPE rather than that which would be hoped
- for, viz: '(real 4 7).
-
+165:
+ Array types with element-types of some unknown type are falsely being
+ assumed to be of type (ARRAY T) by the compiler in some cases. The
+ following code demonstrates the problem:
+
+ (defun foo (x)
+ (declare (type (vector bar) x))
+ (aref x 1))
+ (deftype bar () 'single-float)
+ (foo (make-array 3 :element-type 'bar))
+ -> TYPE-ERROR "The value #(0.0 0.0 0.0) is not of type (VECTOR BAR)."
+ (typep (make-array 3 :element-type 'bar) '(vector bar))
+ -> T
+
+ The easy solution is to make the functions which depend on knowing
+ the upgraded-array-element-type (in compiler/array-tran and
+ compiler/generic/vm-tran as of sbcl-0.7.3.x) be slightly smarter about
+ unknown types; an alternative is to have the
+ specialized-element-type slot in the ARRAY-TYPE structure be
+ *WILD-TYPE* for UNKNOWN-TYPE element types.
+
+166:
+ Compiling
+ (in-package :cl-user)
+ (defstruct uustk)
+ (defmethod permanentize ((uustk uustk))
+ (flet ((frob (hash-table test-for-deletion)
+ )
+ (obj-entry.stale? (oe)
+ (destructuring-bind (key . datum) oe
+ (declare (type simple-vector key))
+ (deny0 (void? datum))
+ (some #'stale? key))))
+ (declare (inline frob obj-entry.stale?))
+ (frob (uustk.args-hash->obj-alist uustk)
+ #'obj-entry.stale?)
+ (frob (uustk.hash->memoized-objs-list uustk)
+ #'objs.stale?))
+ (call-next-method))
+ in sbcl-0.7.3.11 causes an assertion failure,
+ failed AVER:
+ "(NOT
+(AND (NULL (BLOCK-SUCC B))
+ (NOT (BLOCK-DELETE-P B))
+ (NOT (EQ B (COMPONENT-HEAD #)))))"
+
+167:
+ In sbcl-0.7.3.11, compiling the (illegal) code
+ (in-package :cl-user)
+ (defmethod prove ((uustk uustk))
+ (zap ((frob () nil))
+ (frob)))
+ gives the (not terribly clear) error message
+ ; caught ERROR:
+ ; (during macroexpansion of (DEFMETHOD PROVE ...))
+ ; can't get template for (FROB NIL NIL)
+ The problem seems to be that the code walker used by the DEFMETHOD
+ macro is unhappy with the illegal syntax in the method body, and
+ is giving an unclear error message.
+
+168:
+ (reported by Dan Barlow on sbcl-devel 2002-05-10)
+ In sbcl-0.7.3.12, doing
+ (defstruct foo bar baz)
+ (compile nil (lambda (x) (or x (foo-baz x))))
+ gives an error
+ debugger invoked on condition of type SB-INT:BUG:
+ full call to SB-KERNEL:%INSTANCE-REF
+ This is probably a bug in SBCL itself. [...]
+ Since this is a reasonable user error, it shouldn't be reported as
+ an SBCL bug.
+
+171:
+ (reported by Pierre Mai while investigating bug 47):
+ (DEFCLASS FOO () ((A :SILLY T)))
+ signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
DEFUNCT CATEGORIES OF BUGS
IR1-#: