-REPORTING BUGS
+SBCL uses Launchpad to track bugs. The bug database is available at:
-Bugs can be reported on the help mailing list
- sbcl-help@lists.sourceforge.net
-or on the development mailing list
- sbcl-devel@lists.sourceforge.net
+ https://bugs.launchpad.net/sbcl
-Please include enough information in a bug report that someone reading
-it can reproduce the problem, i.e. don't write
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
-but instead
- Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
- In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
- I compile and load the file
- (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
- (LET ((*PRINT-LENGTH* 4))
- (PRINT X Y)))))
- X Y)
- then at the command line type
- (MAKE-FOO)
- the program loops endlessly instead of printing the object.
+Reporting bugs there requires registering at Launchpad. However, bugs
+can also be reported on the mailing list sbcl-bugs, which is
+moderated but does _not_ require subscribing. Simply send email to
+ sbcl-bugs@lists.sourceforge.net
-NOTES:
+and the bug will be checked and added to Launchpad by SBCL maintainers.
-There is also some information on bugs in the manual page and
-in the TODO file. Eventually more such information may move here.
+Historical note: before Launchpad was adopted this file contained a
+list of currently open bugs. If you run into an SBCL bug number in the
+range 1-431 inclusive, it refers to that list.
-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 almost certainly should overwrite the old LAYOUT information
- instead of just punting when a contradictory structure definition
- 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:
- 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, and (3) by their own reasoning, it looks as though
- ANSI may have gotten it wrong. 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.
- However, 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).
- 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 (FUNCTION () 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 should compile without complaint and work correctly either
- on SBCL or on any other 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. 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 "compiling top-level form:" output ought to be condensed.
- Perhaps any number of such consecutive lines ought to turn into a
- single "compiling top-level forms:" line.
-
-10:
- The way that the compiler munges types with arguments together
- with types with no arguments (in e.g. TYPE-EXPAND) leads to
- weirdness visible to the user:
- (DEFTYPE FOO () 'FIXNUM)
- (TYPEP 11 'FOO) => T
- (TYPEP 11 '(FOO)) => T, which seems weird
- (TYPEP 11 'FIXNUM) => T
- (TYPEP 11 '(FIXNUM)) signals an error, as it should
- The situation is complicated by the presence of Common Lisp types
- like UNSIGNED-BYTE (which can either be used in list form or alone)
- so I'm not 100% sure that the behavior above is actually illegal.
- But I'm 90+% sure, and the following related behavior,
- (TYPEP 11 'AND) => T
- treating the bare symbol AND as equivalent to '(AND), is specifically
- forbidden (by the ANSI specification of the AND type).
-
-11:
- It would be nice if the
- caught ERROR:
- (during macroexpansion)
- said what macroexpansion was at fault, e.g.
- caught ERROR:
- (during macroexpansion of IN-PACKAGE,
- during macroexpansion of DEFFOO)
-
-15:
- (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
- '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
- (Also, when this is fixed, we can enable the code in PROCLAIM which
- checks for incompatible FTYPE redeclarations.)
-
-18:
- from DTC on the CMU CL mailing list 25 Feb 2000:
-;;; Compiler fails when this file is compiled.
-;;;
-;;; Problem shows up in delete-block within ir1util.lisp. The assertion
-;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
-;;; fails within bind node branch.
-;;;
-;;; Note that if c::*check-consistency* is enabled then an un-reached
-;;; entry is also reported.
-;;;
-(defun foo (val)
- (declare (values nil))
- nil)
-(defun bug (val)
- (multiple-value-call
- #'(lambda (res)
- (block nil
- (tagbody
- loop
- (when res
- (return nil))
- (go loop))))
- (foo val))
- (catch 'ccc1
- (throw 'ccc1
- (block bbbb
- (tagbody
-
- (let ((ttt #'(lambda () (go cccc))))
- (declare (special ttt))
- (return-from bbbb nil))
-
- cccc
- (return-from bbbb nil))))))
-
-19:
- (I *think* this is a bug. It certainly seems like strange behavior. But
- the ANSI spec is scary, dark, and deep..)
- (FORMAT NIL "~,1G" 1.4) => "1. "
- (FORMAT NIL "~3,1G" 1.4) => "1. "
-
-20:
- from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
- (defclass ccc () ())
- (setf (find-class 'ccc1) (find-class 'ccc))
- (defmethod zut ((c ccc1)) 123)
- 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.
-
-29:
- some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
- (DEFUN BAR? (X)
- (OR (NAR? X)
- (BLOCK USED-BY-SOME-Y?
- (FLET ((FROB (STK)
- (DOLIST (Y STK)
- (UNLESS (REJECTED? Y)
- (RETURN-FROM USED-BY-SOME-Y? T)))))
- (DECLARE (INLINE FROB))
- (FROB (RSTK X))
- (FROB (MRSTK X)))
- NIL)))
- gives
- error in function SB-KERNEL:ASSERT-ERROR:
- The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
- This is still present in sbcl-0.6.8.
-
-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:
- (PRINT #'CLASS-NAME)
- gives
- #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
- It would be nice to make closures have a settable name slot,
- and make things like DEFSTRUCT and FLET, which create closures,
- set helpful values into this slot.
-
-33:
- And as long as we're wishing, it would be awfully nice if INSPECT could
- also report on closures, telling about the values of the bound variables.
-
-35:
- The compiler assumes that any time a function of declared FTYPE
- doesn't signal an error, its arguments were of the declared type.
- E.g. compiling and loading
- (DECLAIM (OPTIMIZE (SAFETY 3)))
- (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DEFUN GAMMA (X) X)
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
- (DEFUN FOO (X)
- (COND ((> (FACTORIAL X) 1.0E6)
- (FORMAT T "too big~%"))
- ((INTEGERP X)
- (FORMAT T "exactly ~S~%" (FACTORIAL X)))
- (T
- (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
- then executing
- (FOO 1.5)
- will cause the INTEGERP case to be selected, giving bogus output a la
- exactly 1.33..
- This violates the "declarations are assertions" principle.
- According to the ANSI spec, in the section "System Class FUNCTION",
- this is a case of "lying to the compiler", but the lying is done
- by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
- not by the unexpectedly general definition of FACTORIAL. In any case,
- "declarations are assertions" means that lying to the compiler should
- cause an error to be signalled, and should not cause a bogus
- result to be returned. Thus, the compiler should not assume
- that arbitrary functions check their argument types. (It might
- make sense to add another flag (CHECKED?) to DEFKNOWN to
- identify functions which *do* check their argument types.)
- (Also, verify that the compiler handles declared function
- return types as assertions.)
-
-38:
- DEFMETHOD doesn't check the syntax of &REST argument lists properly,
- accepting &REST even when it's not followed by an argument name:
- (DEFMETHOD FOO ((X T) &REST) NIL)
-
-41:
- TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
- (DEFTYPE INDEXOID () '(INTEGER 0 1000))
- (DEFUN FOO (X)
- (DECLARE (TYPE INDEXOID X))
- (THE (VALUES INDEXOID)
- (VALUES X)))
- where the implementation of the type check in function FOO
- includes a full call to %TYPEP. There are also some fundamental problems
- with the interpretation of VALUES types (inherited from CMU CL, and
- from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
- mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
-
-42:
- The definitions of SIGCONTEXT-FLOAT-REGISTER and
- %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
- supported on FreeBSD because the floating point state is not saved,
- but at least as of FreeBSD 4.0, the floating point state *is* saved,
- so they could be supported after all. Very likely
- SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
-
-43:
- (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
- Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
- issue with 'union, 'and, 'or etc. So even though according to the
- 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:
- a: (fixed in sbcl-0.6.11.25)
- b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
- should probably be 1.4012985e-45. In SBCL,
- (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
- than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
- exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
- and LEAST-NEGATIVE-LONG-FLOAT.
- c: Many expressions generate floating infinity:
- (/ 1 0.0)
- (/ 1 0.0d0)
- (EXPT 10.0 1000)
- (EXPT 10.0d0 1000)
- PVE's regression tests want them to raise errors. SBCL
- generates the infinities instead, which may or may not be
- conforming behavior.
- d: (in section12.erg) various forms a la
- (FLOAT 1 DOUBLE-FLOAT-EPSILON)
- don't give the right behavior.
-
-46:
- type safety errors reported by Peter Van Eynde July 25, 2000:
- a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
- => #(A B C)
- In general lengths of array type specifications aren't
- checked by COERCE, so it fails when the spec is
- (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
- b: CONCATENATE has the same problem of not checking the length
- of specified output array types. MAKE-SEQUENCE and MAP and
- 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
- be used for input and output as needed. It should fail with
- 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").
-
-47:
- DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
- a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
- doesn't.
- b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
- signal a PROGRAM-ERROR, and doesn't.
- c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
- and other DEFCLASS forms with duplicate specifications in their
- slots, should signal a PROGRAM-ERROR, and doesn't.
- d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
- causes a COMPILER-ERROR.
-
-48:
- SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
- a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
- PROGRAM-ERROR, but SBCL accepts it instead.
- b: SYMBOL-MACROLET should refuse to bind something which is
- declared as a global variable, signalling PROGRAM-ERROR.
- 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 NIL instead.
- e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
- "Component type for Complex is not numeric: (EQL 0)."
- This might be easy to fix; the type system already knows
- that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
- g: The type system isn't all that smart about relationships
- between hairy types, as shown in the type.erg test results,
- e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
-
-51:
- miscellaneous errors reported by Peter Van Eynde July 25, 2000:
- a: (PROGN
- (DEFGENERIC FOO02 (X))
- (DEFMETHOD FOO02 ((X NUMBER)) T)
- (LET ((M (FIND-METHOD (FUNCTION FOO02)
- NIL
- (LIST (FIND-CLASS (QUOTE NUMBER))))))
- (REMOVE-METHOD (FUNCTION FOO02) M)
- (DEFGENERIC FOO03 (X))
- (ADD-METHOD (FUNCTION FOO03) M)))
- should give an error, but SBCL allows it.
- b: READ should probably return READER-ERROR, not the bare
- arithmetic error, when input a la "1/0" or "1e1000" causes
- an arithmetic error.
-
-52:
- It has been reported (e.g. by Peter Van Eynde) that there are
- several metaobject protocol "errors". (In order to fix them, we might
- need to document exactly what metaobject protocol specification
- we're following -- the current code is just inherited from PCL.)
-
-54:
- The implementation of #'+ returns its single argument without
- type checking, e.g. (+ "illegal") => "illegal".
-
-56:
- Attempting to use COMPILE on something defined by DEFMACRO fails:
- (DEFMACRO FOO (X) (CONS X X))
- (COMPILE 'FOO)
-Error in function C::GET-LAMBDA-TO-COMPILE:
- #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-
-58:
- (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
- Note: I looked into fixing this in 0.6.11.15, but gave up. The
- problem seems to be that there are two relevant type methods for
- the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
- INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
- called. This could be fixed, but type dispatch is messy and
- confusing enough already, I don't want to complicate it further.
- Perhaps someday we can make CLOS cross-compiled (instead of compiled
- after bootstrapping) so that we don't need to have the type system
- available before CLOS, and then we can rewrite the type methods to
- CLOS methods, and then expressing the solutions to stuff like this
- should become much more straightforward. -- WHN 2001-03-14
-
-60:
- The debugger LIST-LOCATIONS command doesn't work properly.
-
-61:
- Compiling and loading
- (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
- (FAIL 12)
- then requesting a BACKTRACE at the debugger prompt gives no information
- about where in the user program the problem occurred.
-
-62:
- The compiler is supposed to do type inference well enough that
- the declaration in
- (TYPECASE X
- ((SIMPLE-ARRAY SINGLE-FLOAT)
- (LOCALLY
- (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
- ..))
- ..)
- 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; maybe related to bug #109)
- 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; maybe related to bug #109)
- 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.
-
-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.
-
-78:
- ANSI says in one place that type declarations can be abbreviated even
- when the type name is not a symbol, e.g.
- (DECLAIM ((VECTOR T) *FOOVECTOR*))
- SBCL doesn't support this. But ANSI says in another place that this
- isn't allowed. So it's not clear this is a bug after all. (See the
- e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
- and Pierre Mai.)
-
-79:
- as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
- The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
- an easily guessable temporary filename in a way which might open
- applications using LOAD-FOREIGN to hijacking by malicious users
- on the same machine. Incantations for doing this safely are
- floating around the net in various "how to write secure programs
- despite Unix" documents, and it would be good to (1) fix this in
- LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
- files and make it share the same new safe logic.
-
-82:
- Functions are assigned names based on the context in which they're
- defined. This is less than ideal for the functions which are
- used to implement CLOS methods. E.g. the output of
- (DESCRIBE 'PRINT-OBJECT) lists functions like
- #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
- and
- #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
- It would be better if these functions' names always identified
- them as methods, and identified their generic functions and
- specializers.
-
-83:
- RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
- RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
- the mean of the distribution can be systematically O(0.1%) wrong.
- Just increasing R-I-E-B is probably not a good solution, since
- 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))
- (I stumbled across this when I added an
- (assert (not (eq type1 *wild-type*)))
- in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
- in a type context should probably be translated to T, and so it's
- probably to ask whether it's equal to the T type and then (using the
- EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
- (I haven't tried to investigate this bug enough to guess whether
- there might be any user-level symptoms.)
-
-90:
- a latent cross-compilation/bootstrapping bug: The cross-compilation
- host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
- and possibly elsewhere. Instead, we should use the target system's
- CHAR-CODE-LIMIT. This will probably cause problems if we try to
- bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
- than SBCL does.
-
-91:
- (subtypep '(or (integer -1 1)
- unsigned-byte)
- '(or (rational -1 7)
- unsigned-byte
- (integer -1 1))) => NIL,T
- An analogous problem with SINGLE-FLOAT and REAL types was fixed in
- sbcl-0.6.11.22, but some peculiarites of the RATIO type make it
- awkward to generalize the fix to INTEGER and RATIONAL. It's not
- clear what's the best fix. (See the "bug in type handling" discussion
- on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
-
-93:
- In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
- src/cold/shared.lisp doesn't correctly translate the
- interpreted function
- (defun in-host-compilation-mode (fn)
- (let ((*features* (cons :sb-xc-host *features*))
- ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
- ;; base-target-features.lisp-expr:
- (*shebang-features* (set-difference *shebang-features*
- '(:sb-propagate-float-type
- :sb-propagate-fun-type))))
- (with-additional-nickname ("SB-XC" "SB!XC")
- (funcall fn))))
- No error is reported by the compiler, but when the function is executed,
- it causes an error
- TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
- (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
- :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
-
-94a:
- Inconsistencies between derived and declared VALUES return types for
- DEFUN aren't checked very well. E.g. the logic which successfully
- catches problems like
- (declaim (ftype (function (fixnum) float) foo))
- (defun foo (x)
- (declare (type integer x))
- (values x)) ; wrong return type, detected, gives warning, good!
- fails to catch
- (declaim (ftype (function (t) (values t t)) bar))
- (defun bar (x)
- (values x)) ; wrong number of return values, no warning, bad!
- The cause of this is seems to be that (1) the internal function
- VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
- arguments symmetrically, and (2) when the type checking code was
- written back when when SBCL's code was still CMU CL, the intent
- was that this case
- (declaim (ftype (function (t) t) bar))
- (defun bar (x)
- (values x x)) ; wrong number of return values; should give warning?
- not be warned for, because a two-valued return value is considered
- to be compatible with callers who expects a single value to be
- returned. That intent is probably not appropriate for modern ANSI
- Common Lisp, but fixing this might be complicated because of other
- divergences between auld-style and new-style handling of
- multiple-VALUES types. (Some issues related to this were discussed
- on cmucl-imp at some length sometime in 2000.)
-
-95:
- The facility for dumping a running Lisp image to disk gets confused
- when run without the PURIFY option, and creates an unnecessarily large
- core file (apparently representing memory usage up to the previous
- high-water mark). Moreover, when the file is loaded, it confuses the
- GC, so that thereafter memory usage can never be reduced below that
- level.
-
-96:
- The TRACE facility can't be used on some kinds of functions.
- (Basically, the breakpoint facility was incompletely implemented
- in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
-
-98:
- In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
- CL), out-of-line structure slot setters are horribly inefficient
- whenever the type of the slot is declared, because out-of-line
- structure slot setters are implemented as closures to save space,
- so the compiler doesn't compile the type test into code, but
- instead just saves the type in a lexical closure and interprets it
- at runtime.
- A proper solution involves deciding whether it's really worth
- saving space by implementing structure slot accessors as closures.
- (If it's not worth it, the problem vanishes automatically. If it
- is worth it, there are hacks we could use to force type tests to
- be compiled anyway, and even shared. E.g. we could implement
- an EQUAL hash table mapping from types to compiled type tests,
- and save the appropriate compiled type test as part of each lexical
- closure; or we could make the lexical closures be placeholders
- which overwrite their old definition as a lexical closure with
- a new compiled definition the first time that they're called.)
- As a workaround for the problem, #'(SETF FOO) expressions can
- be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
-(defmacro efficient-setf-function (place-function-name)
- (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
- ;; a workaround for the problem, encouraging the
- ;; inline expansion of the structure accessor, so
- ;; that the compiler can optimize its type test
- (let ((new-value (gensym "NEW-VALUE-"))
- (structure-value (gensym "STRUCTURE-VALUE-")))
- `(lambda (,new-value ,structure-value)
- (setf (,place-function-name ,structure-value)
- ,new-value))))
- ;; no problem, can just use the ordinary expansion
- `(function (setf ,place-function-name))))
-
-99:
- DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from
- (let ((*print-circle* t)) (describe (make-hash-table)))
- is weird,
- #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
- Its SIZE is 16.
- Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
- It holds 0 key/value pairs.
- where the ". (EQL)" and ". (1.0)" substrings are screwups.
- (This is likely a pretty-printer problem which happens to
- be exercised by DESCRIBE, not actually a DESCRIBE problem.)
-
-100:
- There's apparently a bug in CEILING optimization which caused
- Douglas Crosher to patch the CMU CL version. Martin Atzmueller
- applied the patches to SBCL and they didn't seem to cause problems
- (as reported sbcl-devel 2001-05-04). However, since the patches
- modify nontrivial code which was apparently written incorrectly
- the first time around, until regression tests are written I'm not
- comfortable merging the patches in the CVS version of SBCL.
-
-102:
- As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
- requires that SYMBOL-MACROLET refuse to rebind special variables,
- 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
- has been fixed, but the nonconforming behavior remains.)
-
-104:
- (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
- incorrectly:
- DEF-ALIEN-TYPE is
- an external symbol
- in #<PACKAGE "SB-ALIEN">.
- Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
- Macro arguments: (#:whole-470 #:environment-471)
- On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
- /usr/stuff/sbcl/src/code/host-alieneval.lisp
- Created: Monday, March 12, 2001 07:47:43 AM CST
-
-105:
- (DESCRIBE 'STREAM-READ-BYTE)
-
-106:
- (reported by Eric Marsden on cmucl-imp 2001-06-15)
- (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
- as bug 50e)
-
-108:
- (TIME (ROOM T)) reports more than 200 Mbytes consed even for
- a clean, just-started SBCL system. And it seems to be right:
- (ROOM T) can bring a small computer to its knees for a *long*
- time trying to GC afterwards. Surely there's some more economical
- way to implement (ROOM T).
-
-109:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- ;;; This file fails to compile.
- ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
- (in-package :cl-user)
- (defun tst2 ()
- (labels
- ((eff (&key trouble)
- (eff)
- ;; nil
- ;; Uncomment and it works
- ))
- (eff)))
- In SBCL 0.6.12.42, the problem is
- internal error, failed AVER:
- "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
- (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
-
-110:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- ;;; The compiler is flushing the argument type test, and the default
- ;;; case in the cond, so that calling with say a fixnum 0 causes a
- ;;; SIGBUS.
- (declaim (optimize (safety 2) (speed 3)))
- (defun tst (x)
- (declare (type (or string stream) x))
- (cond ((typep x 'string) 'string)
- ((typep x 'stream) 'stream)
- (t
- 'none)))
- The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
- (not the SIGBUS reported in the comment) but that's broken too;
- type declarations are supposed to be treated as assertions unless
- SAFETY 0, so we should be getting a TYPE-ERROR.
-
-111:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; Produces an assertion failures when compiled.
- (defun foo (z)
- (declare (type (or (function (t) t) null) z))
- (let ((z (or z #'identity)))
- (declare (type (function (t) t) z))
- (funcall z 1)))
- The error in sbcl-0.6.12.42 is
- internal error, failed AVER:
- "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
-
-112:
- reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
- collection; apparently originally reported by Bruno Haible
- (in-package :cl-user)
- ;;; From: Bruno Haible
- ;;; Subject: scope of SPECIAL declarations
- ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
- ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
- ;;; 1.4.0 cvs".
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x))
- (declare (special x)) y)))
- ;;; Gives: 0 (this should return 1 according to CLHS)
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x) (x 5))
- (declare (special x)) y)))
- ;;; Gives: 1 (correct).
- The reported results match what we get from the interpreter
- in sbcl-0.6.12.42.
-
-113:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; From: David Gadbois <gadbois@cyc.com>
- ;;;
- ;;; Logical pathnames aren't externalizable.
- ;;; Test case:
- (let ((tempfile "/tmp/test.lisp"))
- (setf (logical-pathname-translations "XXX")
- '(("XXX:**;*.*" "/tmp/**/*.*")))
- (with-open-file (out tempfile :direction :output)
- (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
- (compile-file tempfile))
- The error message in sbcl-0.6.12.42 is
- ; caught ERROR:
- ; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
- ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
-
-115:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; The following invokes a compiler error.
- (declaim (optimize (speed 2) (debug 3)))
- (defun tst ()
- (flet ((m1 ()
- (unwind-protect nil)))
- (if (catch nil)
- (m1)
- (m1))))
- The error message in sbcl-0.6.12.42 is
- internal error, failed AVER:
- "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
-
-117:
- When the compiler inline expands functions, it may be that different
- kinds of return values are generated from different code branches.
- E.g. an inline expansion of POSITION generates integer results
- from one branch, and NIL results from another. When that inline
- expansion is used in a context where only one of those results
- is acceptable, e.g.
- (defun foo (x)
- (aref *a1* (position x *a2*)))
- and the compiler can't prove that the unacceptable branch is
- never taken, then bogus type mismatch warnings can be generated.
- If you need to suppress the type mismatch warnings, you can
- suppress the inline expansion,
- (defun foo (x)
- #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
- (aref *a1* (position x *a2*)))
- or, sometimes, suppress them by declaring the result to be of an
- appropriate type,
- (defun foo (x)
- (aref *a1* (the integer (position x *a2*))))
-
- This is not a new compiler problem in 0.7.0, but the new compiler
- transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
- more conspicuous. If you don't need performance from these functions,
- and the bogus warnings are a nuisance for you, you can return to
- your pre-0.7.0 state of grace with
- #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
-
-118:
- as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
- (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
- (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
- when of course it should be NIL. (He says it only fails for X86,
- not SPARC; dunno about Alpha.)
-
- Also, "the same problem exists for LONG-FLOAT-EPSILON,
- DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
- for the -negative- the + is replaced by a - in the test)."
-
- Raymond Toy comments that this is tricky on the X86 since its FPU
- uses 80-bit precision internally.
-
-120a:
- The compiler incorrectly figures the return type of
- (DEFUN FOO (FRAME UP-FRAME)
- (IF (OR (NOT FRAME)
- T)
- FRAME
- "BAR"))
- as NIL.
-
- This problem exists in CMU CL 18c too. When I reported it on
- cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
- a partial explanation, but no fix has been found yet.
-
-120b:
- Even in sbcl-0.pre7.x, which is supposed to be free of the old
- non-ANSI behavior of treating the function return type inferred
- from the current function definition as a declaration of the
- return type from any function of that name, the return type of NIL
- is attached to FOO in 120a above, and used to optimize code which
- calls FOO.
-
-122:
- There was some sort of screwup in handling of
- (IF (NOT (IGNORE-ERRORS ..))). E.g.
- (defun foo1i ()
- (if (not (ignore-errors
- (make-pathname :host "foo" :directory "!bla" :name "bar")))
- (print "ok")
- (error "notunlessnot")))
- The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
- printing "ok", but instead it's going to the ERROR. This problem
- seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
- 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
- I reverted back to the old weird HANDLER-CASE code. However, I
- think the problem looks like a compiler bug in handling RETURN-FROM,
- so I left the MNA-patched code in HANDLER-CASE (suppressed with
- #+NIL) and I'd like to go back to see whether this really is
- a compiler bug before I delete this BUGS entry.
-
-123:
- The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
- (IN-PACKAGE :SB-KERNEL)
- (TYPE= (SPECIFIER-TYPE '(VECTOR T))
- (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
- Then because of this, the compiler bogusly optimizes
- (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
- to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
- NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
- about type mismatches (probably harmlessly, another instance of bug 117);
- and then cold init died with a segmentation fault.
-
-124:
- As of version 0.pre7.14, SBCL's implementation of MACROLET makes
- the entire lexical environment at the point of MACROLET available
- in the bodies of the macroexpander functions. In particular, it
- allows the function bodies (which run at compile time) to try to
- access lexical variables (which are only defined at runtime).
- It doesn't even issue a warning, which is bad.
-
- The SBCL behavior arguably conforms to the ANSI spec (since the
- spec says that the behavior is undefined, ergo anything conforms).
- However, it would be better to issue a compile-time error.
- Unfortunately I (WHN) don't see any simple way to detect this
- condition in order to issue such an error, so for the meantime
- SBCL just does this weird broken "conforming" thing.
-
- The ANSI standard says, in the definition of the special operator
- MACROLET,
- The macro-expansion functions defined by MACROLET are defined
- in the lexical environment in which the MACROLET form appears.
- Declarations and MACROLET and SYMBOL-MACROLET definitions affect
- the local macro definitions in a MACROLET, but the consequences
- are undefined if the local macro definitions reference any
- local variable or function bindings that are visible in that
- lexical environment.
- Then it seems to contradict itself by giving the example
- (defun foo (x flag)
- (macrolet ((fudge (z)
- ;The parameters x and flag are not accessible
- ; at this point; a reference to flag would be to
- ; the global variable of that name.
- ` (if flag (* ,z ,z) ,z)))
- ;The parameters x and flag are accessible here.
- (+ x
- (fudge x)
- (fudge (+ x 1)))))
- The comment "a reference to flag would be to the global variable
- of the same name" sounds like good behavior for the system to have.
- but actual specification quoted above says that the actual behavior
- is undefined.
-
-125:
- (as reported by Gabe Garza on cmucl-help 2001-09-21)
- (defvar *tmp* 3)
- (defun test-pred (x y)
- (eq x y))
- (defun test-case ()
- (let* ((x *tmp*)
- (func (lambda () x)))
- (print (eq func func))
- (print (test-pred func func))
- (delete func (list func))))
- Now calling (TEST-CASE) gives output
- NIL
- NIL
- (#<FUNCTION {500A9EF9}>)
- 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
- structure classes related by inheritance. As of 0.7.0, SBCL still
- doesn't follow it.
-
-129:
- insufficient syntax checking in MACROLET:
- (defun foo (x)
- (macrolet ((defmacro bar (z) `(+ z z)))
- (bar x)))
- shouldn't compile without error (because of the extra DEFMACRO symbol).
-
-130:
- reported by Alexey Dejneka on sbcl-devel 2001-11-03
- (defun x (x)
- "Return X if X is a non-negative integer."
- (let ((step (lambda (%funcall)
- (lambda (n)
- (cond ((= n 0) 0)
- (t (1+ (funcall %funcall (1- n)))))))))
- (funcall
- ((lambda (a)
- (funcall step (lambda (n)
- (funcall (funcall a a) n))))
- (lambda (a)
- (funcall step (lambda (n)
- (funcall (funcall a a) n)))))
- x)))
- This function returns its argument. But after removing percents it
- does not work: "Result of (1- n) is not a function".
-
-131:
- As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
- the CL:COMPILE function (which is based on the same %COMPILE
- mechanism) get confused by
-(defun sxhash (x)
- (labels ((sxhash-number (x)
- (etypecase x
- (fixnum (sxhash x)) ; through DEFTRANSFORM
- (integer (sb!bignum:sxhash-bignum x))
- (single-float (sxhash x)) ; through DEFTRANSFORM
- (double-float (sxhash x)) ; through DEFTRANSFORM
- #!+long-float (long-float (error "stub: no LONG-FLOAT"))
- (ratio (let ((result 127810327))
- (declare (type fixnum result))
- (mixf result (sxhash-number (numerator x)))
- (mixf result (sxhash-number (denominator x)))
- result))
- (complex (let ((result 535698211))
- (declare (type fixnum result))
- (mixf result (sxhash-number (realpart x)))
- (mixf result (sxhash-number (imagpart x)))
- result))))
- (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
- (declare (type index depthoid))
- (typecase x
- (list
- (if (plusp depthoid)
- (mix (sxhash-recurse (car x) (1- depthoid))
- (sxhash-recurse (cdr x) (1- depthoid)))
- 261835505))
- (instance
- (if (typep x 'structure-object)
- (logxor 422371266
- (sxhash ; through DEFTRANSFORM
- (class-name (layout-class (%instance-layout x)))))
- 309518995))
- (symbol (sxhash x)) ; through DEFTRANSFORM
- (number (sxhash-number x))
- (array
- (typecase x
- (simple-string (sxhash x)) ; through DEFTRANSFORM
- (string (%sxhash-substring x))
- (bit-vector (let ((result 410823708))
- (declare (type fixnum result))
- (dotimes (i (min depthoid (length x)))
- (mixf result (aref x i)))
- result))
- (t (logxor 191020317 (sxhash (array-rank x))))))
- (character
- (logxor 72185131
- (sxhash (char-code x)))) ; through DEFTRANSFORM
- (t 42))))
- (sxhash-recurse x)))
- complaining "function called with two arguments, but wants exactly
- one" about SXHASH-RECURSE. (This might not be strictly a new bug,
- since IIRC post-fork CMU CL has also had problems with &OPTIONAL
- arguments in FLET/LABELS: it might be an old Python bug which is
- only exercised by the new arrangement of the SBCL compiler.)
-
-132:
- Trying to compile
- (DEFUN FOO () (CATCH 0 (PRINT 1331)))
- gives an error
- #<SB-C:TN '0!1> is not valid as the second argument to VOP:
- SB-C:MAKE-CATCH-BLOCK,
- since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
- any of the SCs allowed by the operand restriction:
- (SB-VM::DESCRIPTOR-REG)
- The (CATCH 0 ...) construct is bad style (because of unportability
- of EQ testing of numbers) but it is legal, and shouldn't cause an
- internal compiler error. (This error occurs in sbcl-0.6.13 and in
- 0.pre7.86.flaky7.14.)
-
-133:
- Trying to compile something like
- (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
- (code-obj sb!c-call:unsigned-long)
- (pc-offset sb!c-call:int)
- (old-inst sb!c-call:unsigned-long))
- in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
- cannot use values types here
- probably because the SB-C-CALL:VOID type gets translated to (VALUES).
- It should be valid to use VOID for a function return type, so perhaps
- instead of calling SPECIFIER-TYPE (which excludes all VALUES types
- automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
- types manually, allowing the special case (VALUES) but still excluding
- all more-complex VALUES types.
-
-135:
- Ideally, uninterning a symbol would allow it, and its associated
- FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
- at least as of sbcl-0.7.0, this isn't the case. Information about
- FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
- essentially in ordinary (non-weak) hash tables keyed by symbols.
- Thus, once a system has an entry in this system, it tends to live
- forever, even when it is uninterned and all other references to it
- are lost.
-
-136:
- (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
- (defmethod foo ((x integer))
- x)
- (defmethod foo :around ((x integer))
- (let ((x (1+ x)))
- (call-next-method)))
- Now (FOO 3) should return 3, but instead it returns 4.
-
-137:
- (SB-DEBUG:BACKTRACE) output should start with something
- including the name BACKTRACE, not (as in 0.pre7.88)
- just "0: (\"hairy arg processor\" ...)". Until about
- sbcl-0.pre7.109, the names in BACKTRACE were all screwed
- up compared to the nice useful names in sbcl-0.6.13.
- Around sbcl-0.pre7.109, they were mostly fixed by using
- NAMED-LAMBDA to implement DEFUN. However, there are still
- some screwups left, e.g. as of sbcl-0.pre7.109, there are
- still some functions named "hairy arg processor" and
- "SB-INT:&MORE processor".
-
-138:
- a pair of cross-compiler bugs in sbcl-0.pre7.107
-
-138a:
- $ cat > /tmp/bug138.lisp << EOF
- (in-package "SB!KERNEL")
- (defun f-c-l (name parent-types)
- (let* ((cpl (mapcar (lambda (x)
- (condition-class-cpl x))
- parent-types))
- (new-inherits
- (concatenate 'simple-vector
- (layout-inherits cond-layout))))
- (if (not (mismatch (layout-inherits olayout) new-inherits))
- olayout
- (make-layout))))
- EOF
- $ sbcl --core output/after-xc.core
- ...
- * (target-compile-file "/tmp/bug138.lisp")
- ...
- internal error, failed AVER:
- "(COMMON-LISP:MEMBER SB!C::FUN (SB!C::COMPONENT-LAMBDAS SB!C:COMPONENT))"
-
- It seems as though this xc bug is likely to correspond to a bug in the
- ordinary compiler, but I haven't yet found a test case which causes
- this problem in the ordinary compiler.
-
- related weirdness: Using #'(LAMBDA (X) ...) instead of (LAMBDA (X) ...)
- makes the assertion failure go away.
-
-138b:
- Even when you relax the AVER that fails in 138a, there's another
- problem cross-compiling the same code:
- internal error, failed AVER:
- "(COMMON-LISP:ZEROP
- (COMMON-LISP:HASH-TABLE-COUNT
- (SB!FASL::FASL-OUTPUT-PATCH-TABLE SB!FASL:FASL-OUTPUT)))"
-
- The same problem appears in the simpler test case
- (in-package "SB!KERNEL")
- (defun f-c-l ()
- (let ((cpl (foo (lambda (x)
- (condition-class-cpl x))))
- (new-inherits (layout-inherits cond-layout)))
- (layout-inherits olayout)))
-
- Changing CONDITION-CLASS-CPL or (either of the calls to) LAYOUT-INHERITS
- to arbitrary nonmagic not-defined-yet just-do-a-full-call functions makes
- the problem go away. Also, even in this simpler test case which fails
- on a very different AVER, the 138a weirdness about s/(lambda/#'(lambda/
- making the problem go away is preserved.
-
- I still haven't found any way to make this happen in the ordinary
- (not cross-) SBCL compiler, nor in CMU CL.
-
-138c:
- In sbcl-0.pre7.111 I added an assertion upstream, in IR2-CONVERT-CLOSURE,
- which fails for the test case above but doesn't keep the system
- from cross-compiling itself or passing its tests.
-
-139:
- In sbcl-0.pre7.107, (DIRECTORY "*.*") is broken, as reported by
- Nathan Froyd sbcl-devel 2001-12-28.
-
- Christophe Rhodes suggested (sbcl-devel 2001-12-30) converting
- the MERGED-PATHNAME expression in DEFUN DIRECTORY to
- (merged-pathname (merge-pathnames pathname
- *default-pathname-defaults*))
- This looks right, and fixes this bug, but it interacts with the NODES
- logic in %ENUMERATE-PATHNAMES to create a new bug, so that
- (DIRECTORY "../**/*.*") no longer shows files in the current working
- directory. Probably %ENUMERATE-PATHNAMES (or related logic like
- %ENUMERATE-MATCHES) needs to be patched as well.
-
- Note: The MERGED-PATHNAME change changes behavior incompatibly,
- making e.g. (DIRECTORY "*") no longer equivalent to (DIRECTORY "*.*"),
- so deserves a NEWS entry. E.g.
-* minor incompatible change (part of a bug fix by Christophe Rhodes
- to DIRECTORY behavior): DIRECTORY no longer implicitly promotes
- NIL slots of its pathname argument to :WILD, and in particular
- asking for the contents of a directory, which you used to be able
- to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"),
- now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*").
-
-
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-(Now that the IR1 interpreter has gone away, these should be
-relatively straightforward to fix.)
-
-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.]
-
-IR1-6:
- (another wishlist thing..) Reimplement DEFMACRO to be basically
- like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
+Refer to User Manual for more details.
projects / sbcl.git / blobdiff