-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: "type checking of structure slots"
- a:
- 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.
-
- b: &AUX argument in a boa-constructor without a default value means
- "do not initilize this slot" and does not cause type error. But
- an error may be signalled at read time and it would be good if
- SBCL did it.
-
- c: Reading of not initialized slot sometimes causes SEGV.
-
- d:
- (declaim (optimize (safety 3) (speed 1) (space 1)))
- (defstruct foo
- x y)
- (defstruct (stringwise-foo (:include foo
- (x "x" :type simple-string)
- (y "y" :type simple-string))))
- (defparameter *stringwise-foo*
- (make-stringwise-foo))
- (setf (foo-x *stringwise-foo*) 0)
- (defun frob-stringwise-foo (sf)
- (aref (stringwise-foo-x sf) 0))
- (frob-stringwise-foo *stringwise-foo*)
- SEGV.
-
-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.
-
- As of sbcl-0.7.5, sbcl's cross-compiler does run with
- *TYPE-SYSTEM-INITIALIZED*; however, this bug remains.
-
-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)
- In sbcl-0.7.1.13, this gives an error,
- There is no class named CCC1.
- DTC's recommended workaround from the mailing list 3 Mar 2000:
- (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
-
-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.
-
-32:
- The printer doesn't report closures very well. This is true in
- CMU CL 18b as well:
- (PRINT #'CLASS-NAME)
- gives
- #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
- It would be nice to make closures have a settable name slot,
- and make things like DEFSTRUCT and FLET, which create closures,
- set helpful values into this slot.
-
-33:
- And as long as we're wishing, it would be awfully nice if INSPECT could
- also report on closures, telling about the values of the bound variables.
-
-35:
- The compiler assumes that any time a function of declared FTYPE
- doesn't signal an error, its arguments were of the declared type.
- E.g. compiling and loading
- (DECLAIM (OPTIMIZE (SAFETY 3)))
- (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DEFUN GAMMA (X) X)
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
- (DEFUN FOO (X)
- (COND ((> (FACTORIAL X) 1.0E6)
- (FORMAT T "too big~%"))
- ((INTEGERP X)
- (FORMAT T "exactly ~S~%" (FACTORIAL X)))
- (T
- (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
- then executing
- (FOO 1.5)
- will cause the INTEGERP case to be selected, giving bogus output a la
- exactly 2.5
- 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.
-
-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:
- c: (COERCE 'AND 'FUNCTION) returns something related to
- (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
- 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:
- d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
- causes a COMPILER-ERROR.
-
-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.
-
-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.)
-
-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.
-
-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.
-
-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.
-
-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.
-
- (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
- make the temporary filename less easily guessable)
-
-82:
- Functions are assigned names based on the context in which they're
- defined. This is less than ideal for the functions which are
- used to implement CLOS methods. E.g. the output of
- (DESCRIBE 'PRINT-OBJECT) lists functions like
- #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
- and
- #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
- It would be better if these functions' names always identified
- them as methods, and identified their generic functions and
- specializers.
-
-83:
- RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
- RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
- the mean of the distribution can be systematically O(0.1%) wrong.
- Just increasing R-I-E-B is probably not a good solution, since
- it would decrease efficiency more than is probably necessary. Perhaps
- using some sort of accept/reject method would be better.
-
-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.)
-
- In fact, the type system is likely to depend on this inequality not
- holding... * is not equivalent to T in many cases, such as
- (VECTOR *) /= (VECTOR T).
-
-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.
-
-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.
-
-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).
-
-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.
-
-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.
-
-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.
-
- (Since 0.7.8.23 macroexpanders are defined in a restricted version
- of the lexical environment, containing no lexical variables and
- functions, which seems to conform to ANSI and CLtL2, but signalling
- a STYLE-WARNING for references to variables similar to locals might
- be a good thing.)
-
-125:
- (as reported by Gabe Garza on cmucl-help 2001-09-21)
- (defvar *tmp* 3)
- (defun test-pred (x y)
- (eq x y))
- (defun test-case ()
- (let* ((x *tmp*)
- (func (lambda () x)))
- (print (eq func func))
- (print (test-pred func func))
- (delete func (list func))))
- Now calling (TEST-CASE) gives output
- NIL
- NIL
- (#<FUNCTION {500A9EF9}>)
- Evidently Python thinks of the lambda as a code transformation so
- much that it forgets that it's also an object.
-
-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.
-
-141: "pretty printing and backquote"
- a.
- * '``(FOO ,@',@S)
- ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
-
- b.
- * (write '`(, .ala.) :readably t :pretty t)
- `(,.ALA.)
-
- (note the space between the comma and the point)
-
-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.
-
- See also bugs #45.c and #183
-
-148:
- In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
- (in-package :cl-user)
- (defvar *thing*)
- (defvar *zoom*)
- (defstruct foo bar bletch)
- (defun %zeep ()
- (labels ((kidify1 (kid)
- )
- (kid-frob (kid)
- (if *thing*
- (setf sweptm
- (m+ (frobnicate kid)
- sweptm))
- (kidify1 kid))))
- (declare (inline kid-frob))
- (map nil
- #'kid-frob
- (the simple-vector (foo-bar perd)))))
- fails with
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type SB-C::NODE.
- The location of this failure has moved around as various related
- issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
- NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-
- (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
- expand KID-FROB into %ZEEP. Having partially done it, it sees a call
- of KIDIFY1, which already does not exist. So it gives up on
- expansion, leaving garbage consisting of infinished blocks of the
- partially converted function.)
-
-162:
- (reported by Robert E. Brown 2002-04-16)
- When a function is called with too few arguments, causing the
- debugger to be entered, the uninitialized slots in the bad call frame
- seem to cause GCish problems, being interpreted as tagged data even
- though they're not. In particular, executing ROOM in the
- debugger at that point causes AVER failures:
- * (machine-type)
- "X86"
- * (lisp-implementation-version)
- "0.7.2.12"
- * (typep 10)
- ...
- 0] (room)
- ...
- failed AVER: "(SAP= CURRENT END)"
- (Christophe Rhodes reports that this doesn't occur on the SPARC, which
- isn't too surprising since there are many differences in stack
- implementation and GC conservatism between the X86 and other ports.)
-
-167:
- In sbcl-0.7.3.11, compiling the (illegal) code
- (in-package :cl-user)
- (defmethod prove ((uustk uustk))
- (zap ((frob () nil))
- (frob)))
- gives the (not terribly clear) error message
- ; caught ERROR:
- ; (during macroexpansion of (DEFMETHOD PROVE ...))
- ; can't get template for (FROB NIL NIL)
- The problem seems to be that the code walker used by the DEFMETHOD
- macro is unhappy with the illegal syntax in the method body, and
- is giving an unclear error message.
-
-173:
- The compiler sometimes tries to constant-fold expressions before
- it checks to see whether they can be reached. This can lead to
- bogus warnings about errors in the constant folding, e.g. in code
- like
- (WHEN X
- (WRITE-STRING (> X 0) "+" "0"))
- compiled in a context where the compiler can prove that X is NIL,
- and the compiler complains that (> X 0) causes a type error because
- NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
- caused a full WARNING, which made the bug really annoying because then
- COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
- code. Since then the warning has been downgraded to STYLE-WARNING,
- so it's still a bug but at least it's a little less annoying.
-
-183: "IEEE floating point issues"
- Even where floating point handling is being dealt with relatively
- well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
- accrued-exceptions and current-exceptions part of the fp control
- word don't seem to bear much relation to reality. E.g. on
- SPARC/SunOS:
- * (/ 1.0 0.0)
-
- debugger invoked on condition of type DIVISION-BY-ZERO:
- arithmetic error DIVISION-BY-ZERO signalled
- 0] (sb-vm::get-floating-point-modes)
-
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS NIL
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
- 0] abort
- * (sb-vm::get-floating-point-modes)
- (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
- :ROUNDING-MODE :NEAREST
- :CURRENT-EXCEPTIONS (:INEXACT)
- :ACCRUED-EXCEPTIONS (:INEXACT)
- :FAST-MODE NIL)
-
-187: "type inference confusion around DEFTRANSFORM time"
- (reported even more verbosely on sbcl-devel 2002-06-28 as "strange
- bug in DEFTRANSFORM")
- After the file below is compiled and loaded in sbcl-0.7.5, executing
- (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0)
- at the REPL returns an adjustable vector, which is wrong. Presumably
- somehow the DERIVE-TYPE information for the output values of %WAD is
- being mispropagated as a type constraint on the input values of %WAD,
- and so causing the type test to be optimized away. It's unclear how
- hand-expanding the DEFTRANSFORM would change this, but it suggests
- the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
- invoked at a particular phase) is involved.
- (cl:in-package :sb-c)
- (eval-when (:compile-toplevel)
- ;;; standin for %DATA-VECTOR-AND-INDEX
- (defknown %dvai (array index)
- (values t t)
- (foldable flushable))
- (deftransform %dvai ((array index)
- (vector t)
- *
- :important t)
- (let* ((atype (continuation-type array))
- (eltype (array-type-specialized-element-type atype)))
- (when (eq eltype *wild-type*)
- (give-up-ir1-transform
- "specialized array element type not known at compile-time"))
- (when (not (array-type-complexp atype))
- (give-up-ir1-transform "SIMPLE array!"))
- `(if (array-header-p array)
- (%wad array index nil)
- (values array index))))
- ;;; standin for %WITH-ARRAY-DATA
- (defknown %wad (array index (or index null))
- (values (simple-array * (*)) index index index)
- (foldable flushable))
- ;;; (Commenting out this optimizer causes the bug to go away.)
- (defoptimizer (%wad derive-type) ((array start end))
- (let ((atype (continuation-type array)))
- (when (array-type-p atype)
- (values-specifier-type
- `(values (simple-array ,(type-specifier
- (array-type-specialized-element-type atype))
- (*))
- index index index)))))
- ) ; EVAL-WHEN
- (defun %wad (array start end)
- (format t "~&in %WAD~%")
- (%with-array-data array start end))
- (cl:in-package :cl-user)
- (defun tcx (v i)
- (declare (type (vector t) v))
- (declare (notinline sb-kernel::%with-array-data))
- ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to
- ;; go away.)
- (sb-c::%dvai v i))
-
-188: "compiler performance fiasco involving type inference and UNION-TYPE"
- (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this
- bug could be fixed properly, so you won't see the bug unless you restore
- the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III,
- (time (compile
- nil
- '(lambda ()
- (declare (optimize (safety 3)))
- (declare (optimize (compilation-speed 2)))
- (declare (optimize (speed 1) (debug 1) (space 1)))
- (let ((fn "if-this-file-exists-the-universe-is-strange"))
- (load fn :if-does-not-exist nil)
- (load (concatenate 'string fn ".lisp") :if-does-not-exist nil)
- (load (concatenate 'string fn ".fasl") :if-does-not-exist nil)
- (load (concatenate 'string fn ".misc-garbage")
- :if-does-not-exist nil)))))
- reports
- 134.552 seconds of real time
- 133.35156 seconds of user run time
- 0.03125 seconds of system run time
- [Run times include 2.787 seconds GC run time.]
- 0 page faults and
- 246883368 bytes consed.
- BACKTRACE from Ctrl-C in the compilation shows that the compiler is
- thinking about type relationships involving types like
- #<UNION-TYPE
- (OR (INTEGER 576 576)
- (INTEGER 1192 1192)
- (INTEGER 2536 2536)
- (INTEGER 1816 1816)
- (INTEGER 2752 2752)
- (INTEGER 1600 1600)
- (INTEGER 2640 2640)
- (INTEGER 1808 1808)
- (INTEGER 1296 1296)
- ...)>)[:EXTERNAL]
-
-190: "PPC/Linux pipe? buffer? bug"
- In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
- on the PPC/Linux platform, waiting for a zombie env process. This
- is a classic symptom of buffer filling and deadlock, but it seems
- only sporadically reproducible.
-
-191: "Miscellaneous PCL deficiencies"
- (reported by Alexey Dejneka sbcl-devel 2002-08-04)
- a. DEFCLASS does not inform the compiler about generated
- functions. Compiling a file with
- (DEFCLASS A-CLASS ()
- ((A-CLASS-X)))
- (DEFUN A-CLASS-X (A)
- (WITH-SLOTS (A-CLASS-X) A
- A-CLASS-X))
- results in a STYLE-WARNING:
- undefined-function
- SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
-
- APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
- Mai points out that the declamation of functions is in fact
- incorrect in some cases (most notably for structure
- classes). This means that at present erroneous attempts to use
- WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
- won't get the corresponding STYLE-WARNING.
- c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
- lists and &KEY arguments) do not signal errors when they should.
-
-192: "Python treats free type declarations as promises."
- b. What seemed like the same fundamental problem as bug 192a, but
- was not fixed by the same (APD "more strict type checking
- sbcl-devel 2002-08-97) patch:
- (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
- (declaim (optimize (speed 1) (safety 3)))
- (defun trust-assertion (i)
- (dotimes (j i)
- (declare (type (mod 4) i)) ; when commented out, behavior changes!
- (unless (< i 5)
- (print j))))
- (trust-assertion 6) ; prints nothing unless DECLARE is commented out
-
- (see bug 203)
-
- c. (defun foo (x y)
- (locally (declare (type fixnum x y))
- (+ x (* 2 y))))
- (foo 1.1 2) => 5.1
-
-194: "no error from (THE REAL '(1 2 3)) in some cases"
- fixed parts:
- a. In sbcl-0.7.7.9,
- (multiple-value-prog1 (progn (the real '(1 2 3))))
- returns (1 2 3) instead of signalling an error. This was fixed by
- APD's "more strict type checking patch", but although the fixed
- code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
- it's difficult to write a regression test for it, because
- (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
- still returns (1 2 3).
- still-broken parts:
- b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
- returns (1 2 3). (As above, this shows up when writing regression
- tests for fixed-ness of part a.)
- c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
- d. At the REPL,
- (null (ignore-errors
- (let ((arg1 1)
- (arg2 (identity (the real #(1 2 3)))))
- (if (< arg1 arg2) arg1 arg2))))
- => T
- but putting the same expression inside (DEFUN FOO () ...),
- (FOO) => NIL.
- notes:
- * Actually this entry is probably multiple bugs, as
- Alexey Dejneka commented on sbcl-devel 2002-09-03:)
- I don't think that placing these two bugs in one entry is
- a good idea: they have different explanations. The second
- (min 1 nil) is caused by flushing of unused code--IDENTITY
- can do nothing with it. So it is really bug 122. The first
- (min nil) is due to M-V-PROG1: substituting a continuation
- for the result, it forgets about type assertion. The purpose
- of IDENTITY is to save the restricted continuation from
- inaccurate transformations.
- * Alexey Dejneka pointed out that
- (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
- and
- (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
- work as they should.
-
-201: "Incautious type inference from compound CONS types"
- (reported by APD sbcl-devel 2002-09-17)
- (DEFUN FOO (X)
- (LET ((Y (CAR (THE (CONS INTEGER *) X))))
- (SETF (CAR X) NIL)
- (FORMAT NIL "~S IS ~S, Y = ~S"
- (CAR X)
- (TYPECASE (CAR X)
- (INTEGER 'INTEGER)
- (T '(NOT INTEGER)))
- Y)))
-
- (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
-
-203:
- Compiler does not check THEs on unused values, e.g. in
-
- (progn (the real (list 1)) t)
-
- This situation may appear during optimizing away degenerate cases of
- certain functions: see bug 192b.
-
-205: "environment issues in cross compiler"
- (These bugs have no impact on user code, but should be fixed or
- documented.)
- a. Macroexpanders introduced with MACROLET are defined in the null
- lexical environment.
- b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
- the null lexical environment.
- c. The cross-compiler cannot inline functions defined in a non-null
- lexical environment.
-
-206: ":SB-FLUID feature broken"
- (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
- Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
- the build.
-
-207: "poorly distributed SXHASH results for compound data"
- SBCL's SXHASH could probably try a little harder. ANSI: "the
- intent is that an implementation should make a good-faith
- effort to produce hash-codes that are well distributed
- within the range of non-negative fixnums". But
- (let ((hits (make-hash-table)))
- (dotimes (i 16)
- (dotimes (j 16)
- (let* ((ij (cons i j))
- (newlist (push ij (gethash (sxhash ij) hits))))
- (when (cdr newlist)
- (format t "~&collision: ~S~%" newlist))))))
- reports lots of collisions in sbcl-0.7.8. A stronger MIX function
- would be an obvious way of fix. Maybe it would be acceptably efficient
- to redo MIX using a lookup into a 256-entry s-box containing
- 29-bit pseudorandom numbers?
-
-208: "package confusion in PCL handling of structure slot handlers"
- In sbcl-0.7.8 compiling and loading
- (in-package :cl)
- (defstruct foo (slot (error "missing")) :type list :read-only t)
- (defmethod print-object ((foo foo) stream) (print nil stream))
- causes CERROR "attempting to modify a symbol in the COMMON-LISP
- package: FOO-SLOT". (This is fairly bad code, but still it's hard
- to see that it should cause symbols to be interned in the CL package.)
-
-211: "keywords processing"
- a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
- number of keyword arguments.
- e. Compiling
-
- (flet ((foo (&key y) (list y)))
- (list (foo :y 1 :y 2)))
-
- issues confusing message
-
- ; in: LAMBDA NIL
- ; (FOO :Y 1 :Y 2)
- ;
- ; caught STYLE-WARNING:
- ; The variable #:G15 is defined but never used.
-
-212: "Sequence functions and circular arguments"
- COERCE, MERGE and CONCATENATE go into an infinite loop when given
- circular arguments; it would be good for the user if they could be
- given an error instead (ANSI 17.1.1 allows this behaviour on the part
- of the implementation, as conforming code cannot give non-proper
- sequences to these functions. MAP also has this problem (and
- solution), though arguably the convenience of being able to do
- (MAP 'LIST '+ FOO '#1=(1 . #1#))
- might be classed as more important (though signalling an error when
- all of the arguments are circular is probably desireable).
-
-213: "Sequence functions and type checking"
- a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
- various complicated, though recognizeable, CONS types [e.g.
- (CONS * (CONS * NULL))
- which according to ANSI should be recognized] (and, in SAFETY 3
- code, should return a list of LENGTH 2 or signal an error)
- b. MAP, when given a type argument that is SUBTYPEP LIST, does not
- check that it will return a sequence of the given type. Fixing
- it along the same lines as the others (cf. work done around
- sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
- entirely straightforward.
- c. All of these functions will silently accept a type of the form
- (CONS INTEGER *)
- whether or not the return value is of this type. This is
- probably permitted by ANSI (see "Exceptional Situations" under
- ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
- know about this escape clause, so code of the form
- (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
- can erroneously return T.
-
-214:
- SBCL 0.6.12.43 fails to compile
-
- (locally
- (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
- (flet ((foo (&key (x :vx x-p)) (list x x-p)))
- (foo 1 2)))
-
- or a more simple example:
-
- (locally
- (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
- (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x))))
-
-215: ":TEST-NOT handling by functions"
- a. FIND and POSITION currently signal errors when given non-NIL for
- both their :TEST and (deprecated) :TEST-NOT arguments, but by
- ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
- means that the effect is "unpredictable but harmless". It's not
- clear what that actually means; it may preclude conforming
- implementations from signalling errors.
- b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
- when conflict occurs. As a quality of implementation issue, it
- might be preferable to treat :TEST and :TEST-NOT as being in some
- sense the same &KEY, and effectively take the first test function in
- the argument list.
- c. Again, a quality of implementation issue: it would be good to issue a
- STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
- WARNING for calls with both :TEST and :TEST-NOT; possibly this
- latter should be WARNed about at execute-time too.
-
-216: "debugger confused by frames with invalid number of arguments"
- In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
- leaves the system confused, enough so that (QUIT) no longer works.
- It's as though the process of working with the uninitialized slot in
- the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
- not be the actual problem. (CMU CL 18c doesn't have problems with this.)
-
-217: "Bad type operations with FUNCTION types"
- In sbcl.0.7.7:
-
- * (values-type-union (specifier-type '(function (base-char)))
- (specifier-type '(function (integer))))
-
- #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
-
- It causes insertion of wrong type assertions into generated
- code. E.g.
-
- (defun foo (x s)
- (let ((f (etypecase x
- (character #'write-char)
- (integer #'write-byte))))
- (funcall f x s)
- (etypecase x
- (character (write-char x s))
- (integer (write-byte x s)))))
-
- Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
-
- (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
- produce invalid code, but type checking is not accurate. Similar
- problems exist with VALUES-TYPE-INTERSECTION.)
-
-218: "VALUES type specifier semantics"
- (THE (VALUES ...) ...) in safe code discards extra values.
-
- (defun test (x y) (the (values integer) (truncate x y)))
- (test 10 4) => 2
-
-220:
- Sbcl 0.7.9 fails to compile
-
- (multiple-value-call #'list
- (the integer (helper))
- nil)
-
- Type check for INTEGER, the result of which serves as the first
- argument of M-V-C, is inserted after evaluation of NIL. So arguments
- of M-V-C are pushed in the wrong order. As a temporary workaround
- type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
- would be to put the check between evaluation of arguments, but it
- could be tricky to check result types of PROG1, IF etc.
-
-228: "function-lambda-expression problems"
- in sbcl-0.7.9.6x, from the REPL:
- * (progn (declaim (inline foo)) (defun foo (x) x))
- FOO
- * (function-lambda-expression #'foo)
- (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO
- but this first return value is not suitable for input to FUNCTION or
- COMPILE, as required by ANSI.
-
-229:
- (subtypep 'function '(function)) => nil, t.
-
-233: bugs in constraint propagation
- a.
- (defun foo (x)
- (declare (optimize (speed 2) (safety 3)))
- (let ((y 0d0))
- (values
- (the double-float x)
- (setq y (+ x 1d0))
- (setq x 3d0)
- (quux y (+ y 2d0) (* y 3d0)))))
- (foo 4) => segmentation violation
-
- (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
- (see also bug 236)
-
- b.
- (declaim (optimize (speed 2) (safety 3)))
- (defun foo (x y)
- (if (typep (prog1 x (setq x y)) 'double-float)
- (+ x 1d0)
- (+ x 2)))
- (foo 1d0 5) => segmentation violation
-
-234:
- (fixed in sbcl-0.7.10.36)
-
-235: "type system and inline expansion"
- a.
- (declaim (ftype (function (cons) number) acc))
- (declaim (inline acc))
- (defun acc (c)
- (the number (car c)))
-
- (defun foo (x y)
- (values (locally (declare (optimize (safety 0)))
- (acc x))
- (locally (declare (optimize (safety 3)))
- (acc y))))
-
- (foo '(nil) '(t)) => NIL, T.
-
- b. (reported by brown on #lisp 2003-01-21)
-
- (defun find-it (x)
- (declare (optimize (speed 3) (safety 0)))
- (declare (notinline mapcar))
- (let ((z (mapcar #'car x)))
- (find 'foobar z)))
-
- Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
- LIST.
-
-236: "THE semantics is broken"
-
- (defun foo (a f)
- (declare (optimize (speed 2) (safety 0)))
- (+ 1d0
- (the double-float
- (multiple-value-prog1
- (svref a 0)
- (unless f (return-from foo 0))))))
-
- (foo #(4) nil) => SEGV
-
- VOP selection thinks that in unsafe code result type assertions
- should be valid immediately. (See also bug 233a.)
-
- The similar problem exists for TRULY-THE.
-
-237: "Environment arguments to type functions"
- a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
- UPGRADED-COMPLEX-PART-TYPE now have an optional environment
- argument, but they ignore it completely. This is almost
- certainly not correct.
- b. Also, the compiler's optimizers for TYPEP have not been informed
- about the new argument; consequently, they will not transform
- calls of the form (TYPEP 1 'INTEGER NIL), even though this is
- just as optimizeable as (TYPEP 1 'INTEGER).
-
-DEFUNCT CATEGORIES OF BUGS
- IR1-#:
- These labels were used for bugs related to the old IR1 interpreter.
- The # values reached 6 before the category was closed down.
+Refer to User Manual for more details.
projects / sbcl.git / blobdiff