There is also some information on bugs in the manual page and
in the TODO file. Eventually more such information may move here.
-The gaps in the number sequence belong to old bugs which have been
-fixed.
+The gaps in the number sequence belong to old bug descriptions which
+have gone away (typically because they were fixed, but sometimes for
+other reasons, e.g. because they were moved elsewhere).
KNOWN BUGS OF NO SPECIAL CLASS:
2:
- DEFSTRUCT should almost certainly overwrite the old LAYOUT information
+ DEFSTRUCT almost certainly should overwrite the old LAYOUT information
instead of just punting when a contradictory structure definition
- is loaded.
+ is loaded. As it is, if you redefine DEFSTRUCTs in a way which
+ changes their layout, you probably have to rebuild your entire
+ program, even if you know or guess enough about the internals of
+ SBCL to wager that this (undefined in ANSI) operation would be safe.
3:
- It should cause a STYLE-WARNING, not a full WARNING, when a structure
- slot default value does not match the declared structure slot type.
- (The current behavior is consistent with SBCL's behavior elsewhere,
- and would not be a problem, except that the other behavior is
- specifically required by the ANSI spec.)
-
-4:
- It should cause a note, not a WARNING, when the system ignores
- an FTYPE proclamation for a slot accessor.
-
-5:
- Error reporting on various stream-requiring operations is not
- very good when the stream argument has the wrong type, because
- the operation tries to fall through to Gray stream code, and then
- dies because it's undefined. E.g.
- (PRINT-UNREADABLE-OBJECT (*STANDARD-OUTPUT* 1))
- gives the error message
- error in SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
- The function SB-IMPL::STREAM-WRITE-STRING is undefined.
- It would be more useful and correct to signal a TYPE-ERROR:
- not a STREAM: 1
- (It wouldn't be terribly difficult to write stubs for all the
- Gray stream functions that the old CMU CL code expects, with
- each stub just raising the appropriate TYPE-ERROR.)
+ ANSI specifies that a type mismatch in a structure slot
+ initialization value should not cause a warning.
+WORKAROUND:
+ This one might not be fixed for a while because while we're big
+ believers in ANSI compatibility and all, (1) there's no obvious
+ simple way to do it (short of disabling all warnings for type
+ mismatches everywhere), and (2) there's a good portable
+ workaround. ANSI justifies this specification by saying
+ The restriction against issuing a warning for type mismatches
+ between a slot-initform and the corresponding slot's :TYPE
+ option is necessary because a slot-initform must be specified
+ in order to specify slot options; in some cases, no suitable
+ default may exist.
+ In SBCL, as in CMU CL (or, for that matter, any compiler which
+ really understands Common Lisp types) a suitable default does
+ exist, in all cases, because the compiler understands the concept
+ of functions which never return (i.e. has return type NIL, e.g.
+ ERROR). Thus, as a portable workaround, you can use a call to
+ some known-never-to-return function as the default. E.g.
+ (DEFSTRUCT FOO
+ (BAR (ERROR "missing :BAR argument")
+ :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
+ or
+ (DECLAIM (FTYPE () NIL) MISSING-ARG)
+ (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
+ (ERROR "missing required argument"))
+ (DEFSTRUCT FOO
+ (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
+ (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
+ (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
+ Such code will compile without complaint and work correctly either
+ on SBCL or on a completely compliant Common Lisp system.
6:
bogus warnings about undefined functions for magic functions like
SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
- like src/code/float.lisp
+ like src/code/float.lisp. Fixing this will probably require
+ straightening out enough bootstrap consistency issues that
+ the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
+ Instead, the cross-compiler runs in a slightly flaky state
+ which is sane enough to compile SBCL itself, but which is
+ also unstable in several ways, including its inability
+ to really grok function declarations.
7:
The "byte compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
single "byte compiling top-level forms:" line.
-8:
- Compiling a file containing the erroneous program
- (DEFSTRUCT FOO
- A
- B)
- (DEFSTRUCT (BAR (:INCLUDE FOO))
- A
- B)
- gives only the not-very-useful message
- caught ERROR:
- (during macroexpansion)
- Condition PROGRAM-ERROR was signalled.
- (The specific message which says that the problem was duplicate
- slot names gets lost.)
-
9:
The handling of IGNORE declarations on lambda list arguments of
DEFMETHOD is at least weird, and in fact seems broken and useless.
The ANSI spec says that CONS can be a compound type spec, e.g.
(CONS FIXNUM REAL). SBCL doesn't support this.
-17:
- from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000:
-I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical
-pathname, the type of the corresponding compiled file is X86F:
- * (compile-file "/home/paolo/lisp/tools/foo")
- Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm.
- Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
- Converted SQUARE.
- Compiling DEFUN SQUARE:
- Byte Compiling Top-Level Form:
- /home/paolo/lisp/tools/foo.x86f written.
- Compilation finished in 0:00:00.
- #p"/home/paolo/lisp/tools/foo.x86f"
- NIL
- NIL
-But when the function is called with a logical pathname, the file type
-becomes FASL:
- * (compile-file "tools:foo")
- Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm.
- Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
- Converted SQUARE.
- Compiling DEFUN SQUARE:
- Byte Compiling Top-Level Form:
- TOOLS:FOO.FASL written.
- Compilation finished in 0:00:00.
- #p"/home/paolo/lisp/tools/foo.fasl"
- NIL
- NIL
-
18:
from DTC on the CMU CL mailing list 25 Feb 2000:
;;; Compiler fails when this file is compiled.
Process inferior-lisp exited abnormally with code 1
I haven't noticed a repeatable case of this yet.
-28:
- The system accepts DECLAIM in most places where DECLARE would be
- accepted, without even issuing a warning. ANSI allows this, but since
- it's fairly easy to mistype DECLAIM instead of DECLARE, and the
- meaning is rather different, and it's unlikely that the user
- has a good reason for doing DECLAIM not at top level, it would be
- good to issue a STYLE-WARNING when this happens. A possible
- fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
- or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
-
29:
some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
(DEFUN BAR? (X)
FD-STREAM-MISC-ROUTINE is broken for large files: it says
(THE INDEX SIZE) even though SIZE can be larger than INDEX.
-37:
- In SBCL 0.6.5 (and CMU CL 18b) compiling and loading
- (in-package :cl-user)
- (declaim (optimize (safety 3)
- (debug 3)
- (compilation-speed 2)
- (space 1)
- (speed 2)
- #+nil (sb-ext:inhibit-warnings 2)))
- (declaim (ftype (function * (values)) emptyvalues))
- (defun emptyvalues (&rest rest) (declare (ignore rest)) (values))
- (defstruct foo x y)
- (defgeneric assertoid ((x t)))
- (defmethod assertoid ((x t)) "just a placeholder")
- (defun bar (ht)
- (declare (type hash-table ht))
- (let ((res
- (block blockname
- (progn
- (prog1
- (emptyvalues)
- (assertoid (hash-table-count ht)))))))
- (unless (typep res 'foo)
- (locally
- (common-lisp-user::bad-result-from-assertive-typed-fun
- 'bar
- res)))))
- then executing
- (bar (make-hash-table))
- causes the failure
- Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
- the function C::%INSTANCE-TYPEP is undefined.
- %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for
- some reason -- the (VALUES) return value declaration? -- the optimizer is
- confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist
- as a function) instead.
-
-37a:
- The %INSTANCE-TYPEP problem in bug 37 comes up also when compiling
- and loading
- (IN-PACKAGE :CL-USER)
- (LOCALLY
- (DECLARE (OPTIMIZE (SAFETY 3) (SPEED 2) (SPACE 2)))
- (DECLAIM (FTYPE (FUNCTION (&REST T) (VALUES)) EMPTYVALUES))
- (DEFUN EMPTYVALUES (&REST REST)
- (DECLARE (IGNORE REST))
- (VALUES))
- (DEFSTRUCT DUMMYSTRUCT X Y)
- (DEFUN FROB-EMPTYVALUES (X)
- (LET ((RES (EMPTYVALUES X X X)))
- (UNLESS (TYPEP RES 'DUMMYSTRUCT)
- 'EXPECTED-RETURN-VALUE))))
- (ASSERT (EQ (FROB-EMPTYVALUES 11) 'EXPECTED-RETURN-VALUE))
-
-
38:
DEFMETHOD doesn't check the syntax of &REST argument lists properly,
accepting &REST even when it's not followed by an argument name:
(DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
..))
..)
- is redundant. However, it doesn't. As a quick fix to work around
- the problem, sbcl-0.6.8.10 was patched to automatically add the
- appropriate declarations in the macroexpansion of TYPECASE and
- related macros (thanks to Martin Atzmueller porting Juan Jose
- Garcia Ripoll's CMU CL patch). But the underlying compiler problem
- really should be fixed instead, and at that time the workarounds
- in the TYPECASE-ish expansions should be removed.
+ is redundant. However, as reported by Juan Jose Garcia Ripoll for
+ CMU CL, it sometimes doesn't. Adding declarations is a pretty good
+ workaround for the problem for now, but can't be done by the TYPECASE
+ macros themselves, since it's too hard for the macro to detect
+ assignments to the variable within the clause.
+ Note: The compiler *is* smart enough to do the type inference in
+ many cases. This case, derived from a couple of MACROEXPAND-1
+ calls on Ripoll's original test case,
+ (DEFUN NEGMAT (A)
+ (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
+ (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
+ (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
+ (LET ((I 0) (G2554 LENGTH))
+ (DECLARE (TYPE REAL G2554) (TYPE REAL I))
+ (TAGBODY
+ SB-LOOP::NEXT-LOOP
+ (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
+ (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
+ (GO SB-LOOP::NEXT-LOOP)
+ SB-LOOP::END-LOOP))))))
+ demonstrates the problem; but the problem goes away if the TAGBODY
+ and GO forms are removed (leaving the SETF in ordinary, non-looping
+ code), or if the TAGBODY and GO forms are retained, but the
+ assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
+
+63:
+ Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
+ I am looking into this problem that showed up on the cmucl-help
+ list. It seems to me that the "implementation specific environment
+ hacking functions" found in pcl/walker.lisp are completely messed
+ up. The good thing is that they appear to be barely used within
+ PCL and the munged environment object is passed to cmucl only
+ in calls to macroexpand-1, which is probably why this case fails.
+ SBCL uses essentially the same code, so if the environment hacking
+ is screwed up, it affects us too.
+
+64:
+ Using the pretty-printer from the command prompt gives funny
+ results, apparently because the pretty-printer doesn't know
+ about user's command input, including the user's carriage return
+ that the user, and therefore the pretty-printer thinks that
+ the new output block should start indented 2 or more characters
+ rightward of the correct location.
+
+65:
+ (probably related to bug #70)
+ As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
+ compiling this file
+(in-package "CL-USER")
+(defun equal-terms (termx termy)
+ (labels
+ ((alpha-equal-bound-term-lists (listx listy)
+ (or (and (null listx) (null listy))
+ (and listx listy
+ (let ((bindings-x (bindings-of-bound-term (car listx)))
+ (bindings-y (bindings-of-bound-term (car listy))))
+ (if (and (null bindings-x) (null bindings-y))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (and (= (length bindings-x) (length bindings-y))
+ (prog2
+ (enter-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (exit-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))))))
+ (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
+
+ (alpha-equal-terms (termx termy)
+ (if (and (variable-p termx)
+ (variable-p termy))
+ (equal-bindings (id-of-variable-term termx)
+ (id-of-variable-term termy))
+ (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
+ (alpha-equal-bound-term-lists (bound-terms-of-term termx)
+ (bound-terms-of-term termy))))))
+
+ (or (eq termx termy)
+ (and termx termy
+ (with-variable-invocation (alpha-equal-terms termx termy))))))
+ causes an assertion failure
+ The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
+ (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
+
+ Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
+ case with the same problem:
+(defun parse-fssp-alignment ()
+ ;; Given an FSSP alignment file named by the argument . . .
+ (labels ((get-fssp-char ()
+ (get-fssp-char))
+ (read-fssp-char ()
+ (get-fssp-char)))
+ ;; Stub body, enough to tickle the bug.
+ (list (read-fssp-char)
+ (read-fssp-char))))
+
+66:
+ ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
+ a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
+ (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
+ This also leads to funny behavior when derived type specifiers
+ are used, as originally reported by Milan Zamazal for CMU CL (on the
+ Debian bugs mailing list (?) 2000-02-27), then reported by Martin
+ Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
+ (DEFTYPE FOO () 'SIMPLE-ARRAY)
+ (CONCATENATE 'FOO #(1 2) '(3))
+ => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
+ sequence functions.
+ The derived type specifier FOO should act the same way as the
+ built-in type SIMPLE-ARRAY here, but it doesn't. That problem
+ doesn't seem to exist for sequence types:
+ (DEFTYPE BAR () 'SIMPLE-VECTOR)
+ (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
+
+67:
+ As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
+ and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
+ crashes SBCL. In general tracing anything which is used in the
+ implementation of TRACE is likely to have the same problem.
+
+68:
+ As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
+ SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
+ notably including all PCL instances. There's a limit to how much
+ SXHASH can do to return unique values for instances, but at least
+ 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)
+ The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
+ forms. E.g.
+ (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
+ (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
+ (LET ((ITEM (FIRST SEQ)))
+ (COND ((NULL SEQ)
+ (VALUES NIL NIL))
+ ((FUNCALL TEST OBJ ITEM)
+ (VALUES VAL SEQ))
+ (T
+ (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
+ (FIND-ITEM ITEM SEQUENCE TEST)))
+ from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
+ causes sbcl-0.6.9 to fail with
+ error in function SB-KERNEL:ASSERT-ERROR:
+ The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
+ (SB-C::LAMBDA-TAIL-SET
+ (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
+
+71:
+ (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after
+ (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
+ the previous SPEED policy. This bug will probably get fixed in
+ 0.6.9.x in a general cleanup of optimization policy.
+
+72:
+ (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+73:
+ PROCLAIM and DECLAIM don't recognize the ANSI abbreviated type
+ declaration syntax for user-defined types, although DECLARE does.
+ E.g.
+ (deftype foo () '(integer 3 19))
+ (defvar *foo*)
+ (declaim (foo *foo*)) ; generates warning
+ (defun foo+ (x y)
+ (declare (foo x y)) ; works OK
+ (+ x y))
+
+74:
+ As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
+ gives a result which isn't COMPLEX. The result type optimizer
+ for COERCE doesn't know this, perhaps because it was written before
+ ANSI threw this curveball: the optimizer thinks that COERCE always
+ returns a result of the specified type. Thus while the interpreted
+ function
+ (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
+ returns the correct result,
+ (TRICKY 3) => NIL
+ the compiled function
+ (COMPILE 'TRICKY)
+ does not:
+ (TRICKY 3) => T
+
+75:
+ As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
+ ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
+ :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
+ WITH-OUTPUT-TO-STRING.
+
KNOWN BUGS RELATED TO THE IR1 INTERPRETER
"no!")))
and while EVAL doesn't print the "right now!" messages, the first
FUNCALL on the value returned by EVAL causes both of them to be printed.
+
+IR1-4:
+ The system accepts DECLAIM in most places where DECLARE would be
+ accepted, without even issuing a warning. ANSI allows this, but since
+ it's fairly easy to mistype DECLAIM instead of DECLARE, and the
+ meaning is rather different, and it's unlikely that the user
+ has a good reason for doing DECLAIM not at top level, it would be
+ good to issue a STYLE-WARNING when this happens. A possible
+ fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
+ or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
+ [This is considered an IR1-interpreter-related bug because until
+ EVAL-WHEN is rewritten, which won't happen until after the IR1
+ interpreter is gone, the system's notion of what's a top-level form
+ and what's not will remain too confused to fix this problem.]
projects / sbcl.git / blobdiff