X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=df217516b1ee2c0d1fa241b97c540f2d8eb9a805;hp=5e2693f136294b62cbdb80b315910b7fb054d6ba;hpb=82653abf5573c22c691e2243b70647ecdaa6aea8;p=sbcl.git diff --git a/BUGS b/BUGS index 5e2693f..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,1237 +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, 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.) - -19: - (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep.. -- WHN) - (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. - -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))) - (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.) - -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: - 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 on x86/Linux: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. sbcl-0.7.0.5 - on x86/Linux generates the infinities instead. That might or - might not be conforming behavior, but it's also inconsistent, - which is almost certainly wrong. (Inconsistency: (/ 1 0.0) - should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0) - generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0) - signals an error. - 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 the NIL type instead. - 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". - -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. - -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 - # - 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 wrong 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.) - -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)))) - -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 #. - 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 - -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. - -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: # - -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 - (#) - 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). - -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 - # 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.) - -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". - -140: - (reported by Alexey Dejneka sbcl-devel 2002-01-03) - - SUBTYPEP does not work well with redefined classes: - --- - * (defclass a () ()) - # - * (defclass b () ()) - # - * (subtypep 'b 'a) - NIL - T - * (defclass b (a) ()) - # - * (subtypep 'b 'a) - T - T - * (defclass b () ()) - # - - ;;; And now... - * (subtypep 'b 'a) - T - T - -141: - Pretty-printing nested backquotes doesn't work right, as - reported by Alexey Dejneka sbcl-devel 2002-01-13: - * '``(FOO ,@',@S) - ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - * (lisp-implementation-version) - "0.pre7.129" - -142: - (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16) - %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte - of the naturalized string. We could probably port the patches - from the cmucl-imp mailing list. - -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - -144: - (This was once known as IR1-4, but it lived on even after the - IR1 interpreter went to the big bit bucket in the sky.) - 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.] - -145: - ANSI allows types `(COMPLEX ,FOO) to use very hairy values for - FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL - COMPLEX implementation didn't deal with this, and hasn't been - upgraded to do so. (This doesn't seem to be a high priority - conformance problem, since seems hard to construct useful code - where it matters.) - -146: - Floating point errors are reported poorly. E.g. on x86 OpenBSD - with sbcl-0.7.1, - * (expt 2.0 12777) - debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION: - An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled. - No traps are enabled? How can this be? - It should be possible to be much more specific (overflow, division - by zero, etc.) and of course the "How can this be?" should be fixable. - -147: - (reported by Alexey Dejneka sbcl-devel 2002-01-28) - Compiling a file containing - (deftype digit () '(member #\1)) - (defun parse-num (string ind) - (flet ((digs () - (let (old-index) - (if (and (< ind ind) - (typep (char string ind) 'digit)) - nil)))))) - in sbcl-0.7.1 causes the compiler to fail with - internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" - This problem seems to have been introduced by the sbcl-0.pre7.* compiler - changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related - test case is - (defun parse-num (index) - (let (num x) - (flet ((digs () - (setq num index)) - (z () - (let () - (setq x nil)))) - (when (and (digs) (digs)) x)))) - In sbcl-0.7.1, it failed with the same - internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" - but after the APD patches in sbcl-0.7.1.2 (new consistency check in - TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the - new consistency check from failing routinely) it fails in - FIND-IN-PHYSENV instead: - - -DEFUNCT CATEGORIES OF BUGS - IR1-#: - These numbers were used for bugs related to the old IR1 - interpreter. The # values reached 6 before the category - was closed down. \ No newline at end of file +Refer to User Manual for more details.