ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
(and now SBCL) interpret them as legal types.
-44:
- ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
- CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
- list, and it is probably possible to use substantially the same
- patches to add it to SBCL.
-
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
it binds is declared SPECIAL inside.
-50:
- type system errors reported by Peter Van Eynde July 25, 2000:
- c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
- d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
- blows up at the level of SPECIFIER-TYPE with
- "Lower bound (0) is greater than upper bound (0)." Probably
- SPECIFIER-TYPE should return the NIL type instead.
- g: The type system [still] isn't all that smart about relationships
- between hairy types. [The original example from PVE was
- (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL, which was fixed
- by CSR in sbcl-0.7.1.28, but there are still
- plenty of corner cases out there.]
-
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
a: (PROGN
it should probably look at the class name, the way that it does
for STRUCTURE-OBJECTs.
-69:
- As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
- > There remains one issue, that is a bug in SBCL:
- > According to my interpretation of the spec, the ":" and "@" modifiers
- > should appear _after_ the comma-seperated arguments.
- > Well, SBCL (and CMUCL for that matter) accept
- > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
- > where the correct way (IMHO) should be
- > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
- Probably SBCL should stop accepting the "~:8D"-style format arguments,
- or at least issue a warning.
-
70:
(probably related to bug #65; maybe related to bug #109)
The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
it would decrease efficiency more than is probably necessary. Perhaps
using some sort of accept/reject method would be better.
-84:
- (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
-
85:
Internally the compiler sometimes evaluates
(sb-kernel:type/= (specifier-type '*) (specifier-type t))
issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-150:
- In sbcl-0.7.1.15, compiling this code
- (let* ()
- (flet ((wufn () (glorp table1 4.9)))
- (gleep *uustk* #'wufn "#1" (list)))
- (if (eql (lo foomax 3.2))
- (values)
- (error "not ~S" '(eql (lo foomax 3.2))))
- (values))
- causes a failure in SB-C::ADD-TEST-CONSTRAINTS:
- The value NIL is not of type SB-C::CONTINUATION.
- other notes:
- * The problem appears to be tied to the way that EQL is given only
- one argument, and goes away when we give EQL a second argument.
- * CMU CL 18c has this problem too, exercised by
- (compile nil
- '(lambda ()
- (let* ()
- (flet ((wufn () (glorp table1 4.9)))
- (gleep *uustk* #'wufn "#1" (list)))
- (if (eql (lo foomax 3.2))
- (values)
- (error "not ~S" '(eql (lo foomax 3.2))))
- (values))))
-
-151:
- From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
- should return NIL when there is no definition, e.g.
- (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
- Instead, in sbcl-0.7.1.17 it returns
- #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
-
-152:
- Undefined functions are supposed to be reported as UNDEFINED-FUNCTION
- conditions, inheriting from CELL-ERROR. Instead sbcl-0.7.1.19 reports
- them as TYPE-ERRORs (reporting the problem as something not being
- coerceable to a function).
-
153:
(essentially the same problem as a CMU CL bug reported by Martin
Cracauer on cmucl-imp 2002-02-19)
Is (1 . 1) of type CONS a cons? => NIL
without signalling an error.
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+155:
+ Executing
+ (defclass standard-gadget (basic-gadget) ())
+ (defclass basic-gadget () ())
+ gives an error:
+ The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
+ object #<SB-PCL::STANDARD-CLASS "unbound">.
+ (reported by Brian Spilsbury sbcl-devel 2002-04-09)
DEFUNCT CATEGORIES OF BUGS
IR1-#:
projects / sbcl.git / blobdiff