believers in ANSI compatibility and all, (1) there's no obvious
simple way to do it (short of disabling all warnings for type
mismatches everywhere), and (2) there's a good portable
- workaround. ANSI justifies this specification by saying
+ 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.
- In SBCL, as in CMU CL (or, for that matter, any compiler which
- really understands Common Lisp types) a suitable default does
- exist, in all cases, because the compiler understands the concept
- of functions which never return (i.e. has return type NIL, e.g.
- ERROR). Thus, as a portable workaround, you can use a call to
- some known-never-to-return function as the default. E.g.
+ 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 () NIL) MISSING-ARG)
+ (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 will compile without complaint and work correctly either
- on SBCL or on a completely compliant Common Lisp system.
+ 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
to really grok function declarations.
7:
- The "byte compiling top-level form:" output ought to be condensed.
+ The "compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
- single "byte compiling top-level forms:" line.
+ single "compiling top-level forms:" line.
10:
The way that the compiler munges types with arguments together
(Also, when this is fixed, we can enable the code in PROCLAIM which
checks for incompatible FTYPE redeclarations.)
-18:
- from DTC on the CMU CL mailing list 25 Feb 2000:
-;;; Compiler fails when this file is compiled.
-;;;
-;;; Problem shows up in delete-block within ir1util.lisp. The assertion
-;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
-;;; fails within bind node branch.
-;;;
-;;; Note that if c::*check-consistency* is enabled then an un-reached
-;;; entry is also reported.
-;;;
-(defun foo (val)
- (declare (values nil))
- nil)
-(defun bug (val)
- (multiple-value-call
- #'(lambda (res)
- (block nil
- (tagbody
- loop
- (when res
- (return nil))
- (go loop))))
- (foo val))
- (catch 'ccc1
- (throw 'ccc1
- (block bbbb
- (tagbody
-
- (let ((ttt #'(lambda () (go cccc))))
- (declare (special ttt))
- (return-from bbbb nil))
-
- cccc
- (return-from bbbb nil))))))
-
19:
(I *think* this is a bug. It certainly seems like strange behavior. But
- the ANSI spec is scary, dark, and deep..)
+ the ANSI spec is scary, dark, and deep.. -- WHN)
(FORMAT NIL "~,1G" 1.4) => "1. "
(FORMAT NIL "~3,1G" 1.4) => "1. "
(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))
Process inferior-lisp exited abnormally with code 1
I haven't noticed a repeatable case of this yet.
-29:
- some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
- (DEFUN BAR? (X)
- (OR (NAR? X)
- (BLOCK USED-BY-SOME-Y?
- (FLET ((FROB (STK)
- (DOLIST (Y STK)
- (UNLESS (REJECTED? Y)
- (RETURN-FROM USED-BY-SOME-Y? T)))))
- (DECLARE (INLINE FROB))
- (FROB (RSTK X))
- (FROB (MRSTK X)))
- NIL)))
- gives
- error in function SB-KERNEL:ASSERT-ERROR:
- The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
- This is still present in sbcl-0.6.8.
-
31:
In some cases the compiler believes type declarations on array
elements without checking them, e.g.
E.g. compiling and loading
(DECLAIM (OPTIMIZE (SAFETY 3)))
(DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
+ (DEFUN GAMMA (X) X)
+ (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
(DEFUN FOO (X)
(COND ((> (FACTORIAL X) 1.0E6)
(FORMAT T "too big~%"))
(Also, verify that the compiler handles declared function
return types as assertions.)
-38:
- DEFMETHOD doesn't check the syntax of &REST argument lists properly,
- accepting &REST even when it's not followed by an argument name:
- (DEFMETHOD FOO ((X T) &REST) NIL)
-
41:
TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
(DEFTYPE INDEXOID () '(INTEGER 0 1000))
ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
(and now SBCL) interpret them as legal types.
-44:
- ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
- CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
- list, and it is probably possible to use substantially the same
- patches to add it to SBCL.
-
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
- a: (fixed in sbcl-0.6.11.25)
b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
should probably be 1.4012985e-45. In SBCL,
(/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
and LEAST-NEGATIVE-LONG-FLOAT.
- c: Many expressions generate floating infinity:
+ 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
- generates the infinities instead, which may or may not be
- conforming behavior.
+ 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.
MERGE also have the same problem.
c: (COERCE 'AND 'FUNCTION) returns something related to
(MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
- d: ELT signals SIMPLE-ERROR if its index argument
- isn't a valid index for its sequence argument, but should
- signal TYPE-ERROR instead.
- e: FILE-LENGTH is supposed to signal a type error when its
- argument is not a stream associated with a file, but doesn't.
f: (FLOAT-RADIX 2/3) should signal an error instead of
returning 2.
g: (LOAD "*.lsp") should signal FILE-ERROR.
c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
it binds is declared SPECIAL inside.
-49:
- LOOP bugs reported by Peter Van Eynde July 25, 2000:
- a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
- the definition of WITH clauses given in the ANSI spec, but
- compiles and runs happily in SBCL.
- b: a messy one involving package iteration:
-interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
-Should be: (("blah" "blah2") ("blah2"))
-SBCL: (("blah") ("blah2"))
- * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
- doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
-
-50:
- type system errors reported by Peter Van Eynde July 25, 2000:
- a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
- but should be (VALUES T T) instead.
- b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
- but should be (VALUES T T) instead.
- c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
- d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
- blows up at the level of SPECIFIER-TYPE with
- "Lower bound (0) is greater than upper bound (0)." Probably
- SPECIFIER-TYPE should return NIL instead.
- e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
- "Component type for Complex is not numeric: (EQL 0)."
- This might be easy to fix; the type system already knows
- that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
- f: The type system doesn't know about the condition system,
- so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
- g: The type system isn't all that smart about relationships
- between hairy types, as shown in the type.erg test results,
- e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
-
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
a: (PROGN
need to document exactly what metaobject protocol specification
we're following -- the current code is just inherited from PCL.)
-53:
- another error from Peter Van Eynde 5 September 2000:
- (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
- PVE submitted a patch to deal with this bug, but it exposes other
- comparably serious bugs, so I didn't apply it. It looks as though
- the FORMAT code needs a fair amount of rewriting in order to comply
- with the various details of the ANSI spec.
-
54:
The implementation of #'+ returns its single argument without
type checking, e.g. (+ "illegal") => "illegal".
-56:
- Attempting to use COMPILE on something defined by DEFMACRO fails:
- (DEFMACRO FOO (X) (CONS X X))
- (COMPILE 'FOO)
-Error in function C::GET-LAMBDA-TO-COMPILE:
- #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-
58:
(SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
Note: I looked into fixing this in 0.6.11.15, but gave up. The
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
72:
(DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
-74:
- As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
- gives a result which isn't COMPLEX. The result type optimizer
- for COERCE doesn't know this, perhaps because it was written before
- ANSI threw this curveball: the optimizer thinks that COERCE always
- returns a result of the specified type. Thus while the interpreted
- function
- (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
- returns the correct result,
- (TRICKY 3) => NIL
- the compiled function
- (COMPILE 'TRICKY)
- does not:
- (TRICKY 3) => T
-
75:
As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
files and make it share the same new safe logic.
-80:
- (fixed early Feb 2001 by MNA)
-
-81:
- As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
- 2001-02-14,
- According to CLHS
- (loop with (a . b) of-type float = '(0.0 . 1.0)
- and (c . d) of-type float = '(2.0 . 3.0)
- return (list a b c d))
- should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
- invokes the debugger: "B is not of type list".
- SBCL does the same thing.
-
82:
Functions are assigned names based on the context in which they're
defined. This is less than ideal for the functions which are
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))
(assert (not (eq type1 *wild-type*)))
in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
in a type context should probably be translated to T, and so it's
- probably to ask whether it's equal to the T type and then (using the
- EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+ 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.)
clear what's the best fix. (See the "bug in type handling" discussion
on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
-93:
- In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
- src/cold/shared.lisp doesn't correctly translate the
- interpreted function
- (defun in-host-compilation-mode (fn)
- (let ((*features* (cons :sb-xc-host *features*))
- ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
- ;; base-target-features.lisp-expr:
- (*shebang-features* (set-difference *shebang-features*
- '(:sb-propagate-float-type
- :sb-propagate-fun-type))))
- (with-additional-nickname ("SB-XC" "SB!XC")
- (funcall fn))))
- No error is reported by the compiler, but when the function is executed,
- it causes an error
- TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
- (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
- :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
-
94a:
Inconsistencies between derived and declared VALUES return types for
DEFUN aren't checked very well. E.g. the logic which successfully
;; no problem, can just use the ordinary expansion
`(function (setf ,place-function-name))))
-99:
- DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from
- (let ((*print-circle* t)) (describe (make-hash-table)))
- is weird,
- #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
- Its SIZE is 16.
- Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
- It holds 0 key/value pairs.
- where the ". (EQL)" and ". (1.0)" substrings are screwups.
- (This is likely a pretty-printer problem which happens to
- be exercised by DESCRIBE, not actually a DESCRIBE problem.)
-
100:
There's apparently a bug in CEILING optimization which caused
Douglas Crosher to patch the CMU CL version. Martin Atzmueller
the first time around, until regression tests are written I'm not
comfortable merging the patches in the CVS version of SBCL.
-101:
- The error message for calls to structure accessors with the
- wrong number of arguments is confusing and of the wrong
- condition class (TYPE-ERROR instead of PROGRAM-ERROR):
- * (defstruct foo x y)
- * (foo-x)
- debugger invoked on condition of type SIMPLE-TYPE-ERROR:
- Structure for accessor FOO-X is not a FOO:
- 301988783
-
102:
As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
requires that SYMBOL-MACROLET refuse to rebind special variables,
As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
has been fixed, but the nonconforming behavior remains.)
-103:
- As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's
- definition of (LOOP .. DO ..) requires that the terms following
- DO all be compound forms. SBCL's implementation of LOOP allows
- non-compound forms (like the bare symbol COUNT, in his example)
- here.
-
104:
(DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
incorrectly:
/usr/stuff/sbcl/src/code/host-alieneval.lisp
Created: Monday, March 12, 2001 07:47:43 AM CST
-105:
- (DESCRIBE 'STREAM-READ-BYTE)
-
-106:
- (reported by Eric Marsden on cmucl-imp 2001-06-15)
- Executing
- (TYPEP 0 '(COMPLEX (EQL 0)))
- signals an error in sbcl-0.6.12.34,
- The component type for COMPLEX is not numeric: (EQL 0)
- This is funny since sbcl-0.6.12.34 knows
- (SUBTYPEP '(EQL 0) 'NUMBER) => T
-
108:
(TIME (ROOM T)) reports more than 200 Mbytes consed even for
a clean, just-started SBCL system. And it seems to be right:
type declarations are supposed to be treated as assertions unless
SAFETY 0, so we should be getting a TYPE-ERROR.
-111:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; Produces an assertion failures when compiled.
- (defun foo (z)
- (declare (type (or (function (t) t) null) z))
- (let ((z (or z #'identity)))
- (declare (type (function (t) t) z))
- (funcall z 1)))
- The error in sbcl-0.6.12.42 is
- internal error, failed AVER:
- "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
-
-112:
- reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
- collection; apparently originally reported by Bruno Haible
- (in-package :cl-user)
- ;;; From: Bruno Haible
- ;;; Subject: scope of SPECIAL declarations
- ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
- ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
- ;;; 1.4.0 cvs".
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x))
- (declare (special x)) y)))
- ;;; Gives: 0 (this should return 1 according to CLHS)
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x) (x 5))
- (declare (special x)) y)))
- ;;; Gives: 1 (correct).
- The reported results match what we get from the interpreter
- in sbcl-0.6.12.42.
-
113:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
-114:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; This file causes the byte compiler to fail.
- (declaim (optimize (speed 0) (safety 1)))
- (defun tst1 ()
- (values
- (multiple-value-list
- (catch 'a
- (return-from tst1)))))
- The error message in sbcl-0.6.12.42 is
- internal error, failed AVER:
- "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)"
-
115:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
Raymond Toy comments that this is tricky on the X86 since its FPU
uses 80-bit precision internally.
-119:
- a bug in the byte compiler and/or interpreter: Compile
- (IN-PACKAGE :CL-USER)
- (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1)))
- (DEFUN BAR (&REST DIMS)
- (IF (EVERY #'INTEGERP DIMS)
- 1
- 2))
- then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8
- this gives a TYPE-ERROR,
- The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not
- of type (MOD 536870911).
- The same error will probably occur in earlier versions as well,
- although the name of the uninitialized-element placeholder will
- be shorter.
-
- The same thing happens if the compiler macro expansion of
- EVERY into MAP is hand-expanded:
- (defun bar2 (dims)
- (if (block blockname
- (map nil
- (lambda (dim)
- (let ((pred-value (funcall #'integerp dim)))
- (unless pred-value
- (return-from blockname
- nil))))
- dims)
- t)
- 1
- 2))
- CMU CL doesn't have this compiler macro expansion, so it was
- immune to the original bug in BAR, but once we hand-expand it
- into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
-
- The native compiler handles it fine, both in SBCL and in CMU CL.
-
120a:
The compiler incorrectly figures the return type of
(DEFUN FOO (FRAME UP-FRAME)
is attached to FOO in 120a above, and used to optimize code which
calls FOO.
-121:
- In sbcl-0.7.14.flaky4.10, the last MAPTEST test case at the end
- of tests/map-tests.impure.lisp dies with
- The value
- #<SB-C::MV-COMBINATION
- :FUN #<SB-C::REF
- :LEAF #<SB-C::GLOBAL-VAR
- :NAME +
- :TYPE #
- :WHERE-FROM :DECLARED
- :KIND :GLOBAL-FUNCTION>>
- :ARGS (#<SB-C::COMBINATION :FUN # :ARGS (#)>)>
- is not of type
- SB-C::COMBINATION.
- in
- (SB-C::GENERATE-BYTE-CODE-FOR-REF
- #<SB-ASSEM:SEGMENT :NAME "Byte Output">
- #<SB-C::REF
- :LEAF #<SB-C::GLOBAL-VAR
- :NAME +
- :TYPE #<SB-KERNEL:FUNCTION-TYPE (FUNCTION # NUMBER)>
- :WHERE-FROM :DECLARED
- :KIND :GLOBAL-FUNCTION>>
- #<SB-C::CONTINUATION {506AD995}>)
-
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-(Note: At some point, the pure interpreter (actually a semi-pure
-interpreter aka "the IR1 interpreter") will probably go away, replaced
-by constructs like
- (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
-and at that time these bugs should either go away automatically or
-become more tractable to fix. Until then, they'll probably remain,
-since some of them aren't considered urgent, and the rest are too hard
-to fix as long as so many special cases remain. After the IR1
-interpreter goes away is also the preferred time to start
-systematically exterminating cases where debugging functionality
-(backtrace, breakpoint, etc.) breaks down, since getting rid of the
-IR1 interpreter will reduce the number of special cases we need to
-support.)
-
-IR1-1:
- The FUNCTION special operator doesn't check properly whether its
- argument is a function name. E.g. (FUNCTION (X Y)) returns a value
- instead of failing with an error. (Later attempting to funcall the
- value does cause an error.)
-
-IR1-2:
- COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
- * (DEFUN FOO (X) (- 12 X))
- FOO
- * (COMPILED-FUNCTION-P #'FOO)
- T
-
-IR1-3:
- Executing
- (DEFVAR *SUPPRESS-P* T)
- (EVAL '(UNLESS *SUPPRESS-P*
- (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
- (FORMAT T "surprise!"))))
- prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
- rewritten from scratch to conform to the ANSI definition, abandoning
- the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
- in the original CMU CL source, too). This should be easier to do --
- though still nontrivial -- once the various IR1 interpreter special
- cases are gone.
-
-IR1-3a:
- EVAL-WHEN's idea of what's a toplevel form is even more screwed up
- than the example in IR1-3 would suggest, since COMPILE-FILE and
- COMPILE both print both "right now!" messages when compiling the
- following code,
- (LAMBDA (X)
- (COND (X
- (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
- (PRINT "yes! right now!"))
- "yes!")
- (T
- (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
- (PRINT "no! right now!"))
- "no!")))
- and while EVAL doesn't print the "right now!" messages, the first
- FUNCALL on the value returned by EVAL causes both of them to be printed.
-
-IR1-4:
+122:
+ There was some sort of screwup in handling of
+ (IF (NOT (IGNORE-ERRORS ..))). E.g.
+ (defun foo1i ()
+ (if (not (ignore-errors
+ (make-pathname :host "foo" :directory "!bla" :name "bar")))
+ (print "ok")
+ (error "notunlessnot")))
+ The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
+ printing "ok", but instead it's going to the ERROR. This problem
+ seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
+ 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
+ I reverted back to the old weird HANDLER-CASE code. However, I
+ think the problem looks like a compiler bug in handling RETURN-FROM,
+ so I left the MNA-patched code in HANDLER-CASE (suppressed with
+ #+NIL) and I'd like to go back to see whether this really is
+ a compiler bug before I delete this BUGS entry.
+
+123:
+ The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
+ (IN-PACKAGE :SB-KERNEL)
+ (TYPE= (SPECIFIER-TYPE '(VECTOR T))
+ (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
+ Then because of this, the compiler bogusly optimizes
+ (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
+ to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
+ NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
+ about type mismatches (probably harmlessly, another instance of bug 117);
+ and then cold init died with a segmentation fault.
+
+124:
+ As of version 0.pre7.14, SBCL's implementation of MACROLET makes
+ the entire lexical environment at the point of MACROLET available
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
+ access lexical variables (which are only defined at runtime).
+ It doesn't even issue a warning, which is bad.
+
+ The SBCL behavior arguably conforms to the ANSI spec (since the
+ spec says that the behavior is undefined, ergo anything conforms).
+ However, it would be better to issue a compile-time error.
+ Unfortunately I (WHN) don't see any simple way to detect this
+ condition in order to issue such an error, so for the meantime
+ SBCL just does this weird broken "conforming" thing.
+
+ The ANSI standard says, in the definition of the special operator
+ MACROLET,
+ The macro-expansion functions defined by MACROLET are defined
+ in the lexical environment in which the MACROLET form appears.
+ Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+ the local macro definitions in a MACROLET, but the consequences
+ are undefined if the local macro definitions reference any
+ local variable or function bindings that are visible in that
+ lexical environment.
+ Then it seems to contradict itself by giving the example
+ (defun foo (x flag)
+ (macrolet ((fudge (z)
+ ;The parameters x and flag are not accessible
+ ; at this point; a reference to flag would be to
+ ; the global variable of that name.
+ ` (if flag (* ,z ,z) ,z)))
+ ;The parameters x and flag are accessible here.
+ (+ x
+ (fudge x)
+ (fudge (+ x 1)))))
+ The comment "a reference to flag would be to the global variable
+ of the same name" sounds like good behavior for the system to have.
+ but actual specification quoted above says that the actual behavior
+ is undefined.
+
+125:
+ (as reported by Gabe Garza on cmucl-help 2001-09-21)
+ (defvar *tmp* 3)
+ (defun test-pred (x y)
+ (eq x y))
+ (defun test-case ()
+ (let* ((x *tmp*)
+ (func (lambda () x)))
+ (print (eq func func))
+ (print (test-pred func func))
+ (delete func (list func))))
+ Now calling (TEST-CASE) gives output
+ NIL
+ NIL
+ (#<FUNCTION {500A9EF9}>)
+ Evidently Python thinks of the lambda as a code transformation so
+ much that it forgets that it's also an object.
+
+126:
+ (fixed in 0.pre7.41)
+
+127:
+ The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
+ specifies a precedence rule for name collisions between slot accessors of
+ structure classes related by inheritance. As of 0.7.0, SBCL still
+ doesn't follow it.
+
+129:
+ insufficient syntax checking in MACROLET:
+ (defun foo (x)
+ (macrolet ((defmacro bar (z) `(+ z z)))
+ (bar x)))
+ shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+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.)
+
+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 () ())
+ #<STANDARD-CLASS A>
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ NIL
+ T
+ * (defclass b (a) ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ T
+ T
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+
+ ;;; And now...
+ * (subtypep 'b 'a)
+ T
+ T
+
+ This is probably due to underzealous clearing of the type caches; a
+ brute-force solution in that case would be to make a defclass expand
+ into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
+ but there may be a better solution.
+
+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
interpreter is gone, the system's notion of what's a top-level form
and what's not will remain too confused to fix this problem.]
-IR1-6:
- (another wishlist thing..) Reimplement DEFMACRO to be basically
- like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
+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, this second test case failed with the same
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ 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) this second test case
+ failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
+ closing over unreferenced variables) made this second test case
+ compile without error, but the original test case still fails.
+
+ Another way to get rid of the DEFTYPE without changing the symptom
+ of the bug is
+ (defvar *ch*)
+ (defun parse-num (string ind)
+ (flet ((digs ()
+ (let ()
+ (if (and (< ind ind)
+ (sb-int:memq *ch* '(#\1)))
+ nil))))))
+ In sbcl-0.7.1.3, this fails with
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ The problem occurs while the inline expansion of MEMQ,
+ #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
+ is being LET-converted after having its second REF deleted, leaving
+ it with only one entry in LEAF-REFS.
+
+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.
+
+153:
+ (essentially the same problem as a CMU CL bug reported by Martin
+ Cracauer on cmucl-imp 2002-02-19)
+ There is a hole in structure slot type checking. Compiling and LOADing
+ (declaim (optimize safety))
+ (defstruct foo
+ (bla 0 :type fixnum))
+ (defun f ()
+ (let ((foo (make-foo)))
+ (setf (foo-bla foo) '(1 . 1))
+ (format t "Is ~a of type ~a a cons? => ~a~%"
+ (foo-bla foo)
+ (type-of (foo-bla foo))
+ (consp (foo-bla foo)))))
+ (f)
+ should signal an error, but in sbcl-0.7.1.21 instead gives the output
+ Is (1 . 1) of type CONS a cons? => NIL
+ without signalling an error.
+
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+155:
+ Executing
+ (defclass standard-gadget (basic-gadget) ())
+ (defclass basic-gadget () ())
+ gives an error:
+ The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
+ object #<SB-PCL::STANDARD-CLASS "unbound">.
+ (reported by Brian Spilsbury sbcl-devel 2002-04-09)
+
+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.
projects / sbcl.git / blobdiff