X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=df217516b1ee2c0d1fa241b97c540f2d8eb9a805;hp=637e51e0f53100e2dd251abe139b637733976a2f;hpb=fc047ff117f27af43d5d78ddc28ddac24739653b;p=sbcl.git diff --git a/BUGS b/BUGS index 637e51e..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,1266 +1,17 @@ -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. 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. 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. - -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 "~" 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 - # - 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))) - (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. - d: ELT signals SIMPLE-ERROR if its index argument - isn't a valid index for its sequence argument, but should - signal TYPE-ERROR instead. - e: FILE-LENGTH is supposed to signal a type error when its - argument is not a stream associated with a file, but doesn't. - 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. - -49: - LOOP bugs reported by Peter Van Eynde July 25, 2000: - a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to - the definition of WITH clauses given in the ANSI spec, but - compiles and runs happily in SBCL. - b: a messy one involving package iteration: -interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)))) -Should be: (("blah" "blah2") ("blah2")) -SBCL: (("blah") ("blah2")) - * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I)) - doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause. - -50: - type system errors reported by Peter Van Eynde July 25, 2000: - a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. - 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. - f: The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. - 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.) - -53: - another error from Peter Van Eynde 5 September 2000: - (FORMAT NIL "~F" "FOO") should work, but instead reports an error. - PVE submitted a patch to deal with this bug, but it exposes other - comparably serious bugs, so I didn't apply it. It looks as though - the FORMAT code needs a fair amount of rewriting in order to comply - with the various details of the ANSI spec. - -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: - # 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)) - => # 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. - -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. - -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. - -80: - (fixed early Feb 2001 by MNA) - -81: - As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help - 2001-02-14, - According to CLHS - (loop with (a . b) of-type float = '(0.0 . 1.0) - and (c . d) of-type float = '(2.0 . 3.0) - return (list a b c d)) - should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and - invokes the debugger: "B is not of type list". - SBCL does the same thing. - -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 - # - and - # - 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, - # 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. - -101: - The error message for calls to structure accessors with the - wrong number of arguments is confusing and of the wrong - condition class (TYPE-ERROR instead of PROGRAM-ERROR): - * (defstruct foo x y) - * (foo-x) - debugger invoked on condition of type SIMPLE-TYPE-ERROR: - Structure for accessor FOO-X is not a FOO: - 301988783 - -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.) - -103: - As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's - definition of (LOOP .. DO ..) requires that the terms following - DO all be compound forms. SBCL's implementation of LOOP allows - non-compound forms (like the bare symbol COUNT, in his example) - here. - -104: - (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list - incorrectly: - DEF-ALIEN-TYPE is - an external symbol - in #. - Macro-function: # - 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) - Executing - (TYPEP 0 '(COMPLEX (EQL 0))) - signals an error in sbcl-0.6.12.34, - The component type for COMPLEX is not numeric: (EQL 0) - This is funny since sbcl-0.6.12.34 knows - (SUBTYPEP '(EQL 0) 'NUMBER) => T - -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 - ;;; - ;;; 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 #) - ; A logical host can't be dumped as a constant: # - -114: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; This file causes the byte compiler to fail. - (declaim (optimize (speed 0) (safety 1))) - (defun tst1 () - (values - (multiple-value-list - (catch 'a - (return-from tst1))))) - The error message in sbcl-0.6.12.42 is - internal error, failed AVER: - "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)" - -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. - -119: - a bug in the byte compiler and/or interpreter: Compile - (IN-PACKAGE :CL-USER) - (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1))) - (DEFUN BAR (&REST DIMS) - (IF (EVERY #'INTEGERP DIMS) - 1 - 2)) - then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8 - this gives a TYPE-ERROR, - The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not - of type (MOD 536870911). - The same error will probably occur in earlier versions as well, - although the name of the uninitialized-element placeholder will - be shorter. - - The same thing happens if the compiler macro expansion of - EVERY into MAP is hand-expanded: - (defun bar2 (dims) - (if (block blockname - (map nil - (lambda (dim) - (let ((pred-value (funcall #'integerp dim))) - (unless pred-value - (return-from blockname - nil)))) - dims) - t) - 1 - 2)) - CMU CL doesn't have this compiler macro expansion, so it was - immune to the original bug in BAR, but once we hand-expand it - into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).) - - The native compiler handles it fine, both in SBCL and in CMU CL. - -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. - - -KNOWN BUGS RELATED TO THE IR1 INTERPRETER - -(Note: At some point, the pure interpreter (actually a semi-pure -interpreter aka "the IR1 interpreter") will probably go away, replaced -by constructs like - (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) -and at that time these bugs should either go away automatically or -become more tractable to fix. Until then, they'll probably remain, -since some of them aren't considered urgent, and the rest are too hard -to fix as long as so many special cases remain. After the IR1 -interpreter goes away is also the preferred time to start -systematically exterminating cases where debugging functionality -(backtrace, breakpoint, etc.) breaks down, since getting rid of the -IR1 interpreter will reduce the number of special cases we need to -support.) - -IR1-1: - The FUNCTION special operator doesn't check properly whether its - argument is a function name. E.g. (FUNCTION (X Y)) returns a value - instead of failing with an error. (Later attempting to funcall the - value does cause an error.) - -IR1-2: - COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -IR1-3: - Executing - (DEFVAR *SUPPRESS-P* T) - (EVAL '(UNLESS *SUPPRESS-P* - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (FORMAT T "surprise!")))) - prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be - rewritten from scratch to conform to the ANSI definition, abandoning - the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and - in the original CMU CL source, too). This should be easier to do -- - though still nontrivial -- once the various IR1 interpreter special - cases are gone. - -IR1-3a: - EVAL-WHEN's idea of what's a toplevel form is even more screwed up - than the example in IR1-3 would suggest, since COMPILE-FILE and - COMPILE both print both "right now!" messages when compiling the - following code, - (LAMBDA (X) - (COND (X - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "yes! right now!")) - "yes!") - (T - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "no! right now!")) - "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.] - -IR1-6: - (another wishlist thing..) Reimplement DEFMACRO to be basically - like DEFMACRO-MUNDANELY, just using EVAL-WHEN. +Refer to User Manual for more details.