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.
-
-9:
- The handling of IGNORE declarations on lambda list arguments of
- DEFMETHOD is at least weird, and in fact seems broken and useless.
- I should fix up another layer of binding, declared IGNORABLE, for
- typed lambda list arguments.
+ single "compiling top-level forms:" line.
10:
The way that the compiler munges types with arguments together
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 someday perhaps I'll be motivated to look it up..
+ 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
(during macroexpansion of IN-PACKAGE,
during macroexpansion of DEFFOO)
-12:
- The type system doesn't understand the KEYWORD type very well:
- (SUBTYPEP 'KEYWORD 'SYMBOL) => NIL, NIL
- It might be possible to fix this by changing the definition of
- KEYWORD to (AND SYMBOL (SATISFIES KEYWORDP)), but the type system
- would need to be a bit smarter about AND types, too:
- (SUBTYPEP '(AND SYMBOL KEYWORD) 'SYMBOL) => NIL, NIL
- (The type system does know something about AND types already,
- (SUBTYPEP '(AND INTEGER FLOAT) 'NUMBER) => T, T
- (SUBTYPEP '(AND INTEGER FIXNUM) 'NUMBER) =>T, T
- so likely this is a small patch.)
-
-13:
- Floating point infinities are screwed up. [When I was converting CMU CL
- to SBCL, I was looking for complexity to delete, and I thought it was safe
- to just delete support for floating point infinities. It wasn't: they're
- generated by the floating point hardware even when we remove support
- for them in software. -- WHN] Support for them should be restored.
-
-14:
- The ANSI syntax for non-STANDARD method combination types in CLOS is
- (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
- (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
- If you mess this up, omitting the PROGN qualifier in in DEFMETHOD,
- (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
- (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER))
- the error mesage is not easy to understand:
- INVALID-METHOD-ERROR was called outside the dynamic scope
- of a method combination function (inside the body of
- DEFINE-METHOD-COMBINATION or a method on the generic
- function COMPUTE-EFFECTIVE-METHOD).
- It would be better if it were more informative, a la
- The method combination type for this method (STANDARD) does
- not match the method combination type for the generic function
- (PROGN).
- Also, after you make the mistake of omitting the PROGN qualifier
- on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier
- no longer works:
- (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
- gives
- INVALID-METHOD-ERROR was called outside the dynamic scope
- of a method combination function (inside the body of
- DEFINE-METHOD-COMBINATION or a method on the generic
- function COMPUTE-EFFECTIVE-METHOD).
- This is not very helpful..
-
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.)
-16:
- The ANSI spec says that CONS can be a compound type spec, e.g.
- (CONS FIXNUM REAL). SBCL doesn't support this.
-
-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. "
munge12egnum
NIL
-23:
- When too many files are opened, OPEN will fail with an
- uninformative error message
- error in function OPEN: error opening #P"/tmp/foo.lisp": NIL
- instead of saying that too many files are open.
-
-24:
- Right now, when COMPILE-FILE has a read error, it actually pops
- you into the debugger before giving up on the file. It should
- instead handle the error, perhaps issuing (and handling)
- a secondary error "caught ERROR: unrecoverable error during compilation"
- and then return with FAILURE-P true,
-
-25:
- from CMU CL mailing list 01 May 2000
-
-I realize I can take care of this by doing (proclaim (ignore pcl::.slots1.))
-but seeing as .slots0. is not-exported, shouldn't it be ignored within the
-+expansion
-when not used?
-
-In: DEFMETHOD FOO-BAR-BAZ (RESOURCE-TYPE)
- (DEFMETHOD FOO-BAR-BAZ
- ((SELF RESOURCE-TYPE))
- (SETF (SLOT-VALUE SELF 'NAME) 3))
---> BLOCK MACROLET PCL::FAST-LEXICAL-METHOD-FUNCTIONS
---> PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET
---> PCL::BIND-LEXICAL-METHOD-FUNCTIONS LET PCL::BIND-ARGS LET* PCL::PV-BINDING
---> PCL::PV-BINDING1 PCL::PV-ENV LET
-==>
- (LET ((PCL::.SLOTS0. #))
- (PROGN SELF)
- (BLOCK FOO-BAR-BAZ
- (LET #
- #)))
-Warning: Variable PCL::.SLOTS0. defined but never used.
-
-Compilation unit finished.
- 1 warning
-
-#<Standard-Method FOO-BAR-BAZ (RESOURCE-TYPE) {480918FD}>
-
-26:
- reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
-
-Also, there is another bug: `array-displacement' should return an array
-or nil as first value (as per ANSI CL), while CMUCL declares it as
-returning an array as first value always.
-
27:
Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
Process inferior-lisp exited abnormally with code 1
I haven't noticed a repeatable case of this yet.
-29:
- some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
- (DEFUN BAR? (X)
- (OR (NAR? X)
- (BLOCK USED-BY-SOME-Y?
- (FLET ((FROB (STK)
- (DOLIST (Y STK)
- (UNLESS (REJECTED? Y)
- (RETURN-FROM USED-BY-SOME-Y? T)))))
- (DECLARE (INLINE FROB))
- (FROB (RSTK X))
- (FROB (MRSTK X)))
- NIL)))
- gives
- error in function SB-KERNEL:ASSERT-ERROR:
- The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
- This is still present in sbcl-0.6.8.
-
-30:
- The CMU CL reader code takes liberties in binding the standard read table
- when reading the names of characters. Tim Moore posted a patch to the
- CMU CL mailing list Mon, 22 May 2000 21:30:41 -0700.
-
31:
In some cases the compiler believes type declarations on array
elements without checking them, e.g.
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.
-34:
- as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000:
- $ cat xx.lisp
- (defconstant +a-constant+ (make-instance 'a-class))
- (defconstant +another-constant+ (vector +a-constant+))
- $ lisp
- CMU Common Lisp release x86-linux 2.4.19 8 February 2000 build 456,
- running on
- bobby
- Send bug reports and questions to your local CMU CL maintainer,
- or to pvaneynd@debian.org
- or to cmucl-help@cons.org. (prefered)
- type (help) for help, (quit) to exit, and (demo) to see the demos
- Loaded subsystems:
- Python 1.0, target Intel x86
- CLOS based on PCL version: September 16 92 PCL (f)
- * (defclass a-class () ())
- #<STANDARD-CLASS A-CLASS {48027BD5}>
- * (compile-file "xx.lisp")
- Python version 1.0, VM version Intel x86 on 12 JUN 00 08:12:55 am.
- Compiling:
- /home/strandh/Research/Functional/Common-Lisp/CLIM/Development/McCLIM
- /xx.lisp 12 JUN 00 07:47:14 am
- Compiling Load Time Value of (PCL::GET-MAKE-INSTANCE-FUNCTION-SYMBOL
- '(A-CLASS NIL NIL)):
- Byte Compiling Top-Level Form:
- Error in function C::DUMP-STRUCTURE: Attempt to dump invalid
- structure:
- #<A-CLASS {4803A5B5}>
- How did this happen?
-
35:
The compiler assumes that any time a function of declared FTYPE
doesn't signal an error, its arguments were of the declared type.
E.g. compiling and loading
(DECLAIM (OPTIMIZE (SAFETY 3)))
(DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
+ (DEFUN GAMMA (X) X)
+ (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
(DEFUN FOO (X)
(COND ((> (FACTORIAL X) 1.0E6)
(FORMAT T "too big~%"))
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.)
-
-36:
- As pointed out by Martin Cracauer on the CMU CL mailing list
- 13 Jun 2000, the :FILE-LENGTH operation for
- FD-STREAM-MISC-ROUTINE is broken for large files: it says
- (THE INDEX SIZE) even though SIZE can be larger than INDEX.
-
-37:
- In SBCL 0.6.5 (and CMU CL 18b) compiling and loading
- (in-package :cl-user)
- (declaim (optimize (safety 3)
- (debug 3)
- (compilation-speed 2)
- (space 1)
- (speed 2)
- #+nil (sb-ext:inhibit-warnings 2)))
- (declaim (ftype (function * (values)) emptyvalues))
- (defun emptyvalues (&rest rest) (declare (ignore rest)) (values))
- (defstruct foo x y)
- (defgeneric assertoid ((x t)))
- (defmethod assertoid ((x t)) "just a placeholder")
- (defun bar (ht)
- (declare (type hash-table ht))
- (let ((res
- (block blockname
- (progn
- (prog1
- (emptyvalues)
- (assertoid (hash-table-count ht)))))))
- (unless (typep res 'foo)
- (locally
- (common-lisp-user::bad-result-from-assertive-typed-fun
- 'bar
- res)))))
- then executing
- (bar (make-hash-table))
- causes the failure
- Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
- the function C::%INSTANCE-TYPEP is undefined.
- %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for
- some reason -- the (VALUES) return value declaration? -- the optimizer is
- confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist
- as a function) instead.
-
-37a:
- The %INSTANCE-TYPEP problem in bug 37 comes up also when compiling
- and loading
- (IN-PACKAGE :CL-USER)
- (LOCALLY
- (DECLARE (OPTIMIZE (SAFETY 3) (SPEED 2) (SPACE 2)))
- (DECLAIM (FTYPE (FUNCTION (&REST T) (VALUES)) EMPTYVALUES))
- (DEFUN EMPTYVALUES (&REST REST)
- (DECLARE (IGNORE REST))
- (VALUES))
- (DEFSTRUCT DUMMYSTRUCT X Y)
- (DEFUN FROB-EMPTYVALUES (X)
- (LET ((RES (EMPTYVALUES X X X)))
- (UNLESS (TYPEP RES 'DUMMYSTRUCT)
- 'EXPECTED-RETURN-VALUE))))
- (ASSERT (EQ (FROB-EMPTYVALUES 11) 'EXPECTED-RETURN-VALUE))
-
-
-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)
-
-39:
- On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote
-
- Hannu Rummukainen wrote:
- ...
- > There's something weird going on with the compilation of the attached
- > code. Compiling and loading the file in a fresh lisp, then invoking
- > (test-it) gives
- Thanks for the bug report, nice to have this one fixed. It was a bug
- in the x86 backend, the < VOP. A fix has been committed to the main
- source, see the file compiler/x86/float.lisp.
-
- Probably the same bug exists in SBCL.
-
-40:
- TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel,
- so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET))
- returns (VALUES T T). Probably it should be an error instead,
- complaining that the type SOMETHING-NOT-DEFINED-YET is not defined.
+ (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
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
- a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
- Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
- aren't found.
+ 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
(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, but then blow it by being unable to
- output the infinities, since support for infinities is generally
- broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
- undefined.
+ conforming behavior.
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
"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.
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".
-55:
- In sbcl-0.6.7, there is no doc string for CL:PUSH, probably
- because it's defined with the DEFMACRO-MUNDANELY macro and something
- is wrong with doc string setting in that macro.
-
56:
Attempting to use COMPILE on something defined by DEFMACRO fails:
(DEFMACRO FOO (X) (CONS X X))
#<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
58:
- (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
- => NIL, NIL
-
-59:
- CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
- current working directory). And there's no supported way to update
- or query the current working directory (a la Unix "chdir" and "pwd"),
- which is functionality that ILISP needs (and currently gets with low-level
- hacks).
+ (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.
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")
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))
0.6.9.x in a general cleanup of optimization policy.
72:
- (DECLAIM (OPTIMIZE ..)) doesn't work inside LOCALLY.
+ (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+75:
+ As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
+ ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
+ :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
+ WITH-OUTPUT-TO-STRING.
+
+78:
+ ANSI says in one place that type declarations can be abbreviated even
+ when the type name is not a symbol, e.g.
+ (DECLAIM ((VECTOR T) *FOOVECTOR*))
+ SBCL doesn't support this. But ANSI says in another place that this
+ isn't allowed. So it's not clear this is a bug after all. (See the
+ e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
+ and Pierre Mai.)
+
+79:
+ as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
+ The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
+ an easily guessable temporary filename in a way which might open
+ applications using LOAD-FOREIGN to hijacking by malicious users
+ on the same machine. Incantations for doing this safely are
+ floating around the net in various "how to write secure programs
+ despite Unix" documents, and it would be good to (1) fix this in
+ LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
+ files and make it share the same new safe logic.
+
+82:
+ Functions are assigned names based on the context in which they're
+ defined. This is less than ideal for the functions which are
+ used to implement CLOS methods. E.g. the output of
+ (DESCRIBE 'PRINT-OBJECT) lists functions like
+ #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
+ and
+ #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
+ It would be better if these functions' names always identified
+ them as methods, and identified their generic functions and
+ specializers.
+
+83:
+ RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
+ RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
+ the mean of the distribution can be systematically O(0.1%) wrong.
+ Just increasing R-I-E-B is probably not a good solution, since
+ it would decrease efficiency more than is probably necessary. Perhaps
+ using some sort of accept/reject method would be better.
+
+84:
+ (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
+
+85:
+ Internally the compiler sometimes evaluates
+ (sb-kernel:type/= (specifier-type '*) (specifier-type t))
+ (I stumbled across this when I added an
+ (assert (not (eq type1 *wild-type*)))
+ in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
+ in a type context should probably be translated to T, and so it's
+ probably to ask whether it's equal to the T type and then (using the
+ EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+ (I haven't tried to investigate this bug enough to guess whether
+ there might be any user-level symptoms.)
+
+90:
+ a latent cross-compilation/bootstrapping bug: The cross-compilation
+ host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
+ and possibly elsewhere. Instead, we should use the target system's
+ CHAR-CODE-LIMIT. This will probably cause problems if we try to
+ bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
+ than SBCL does.
+
+91:
+ (subtypep '(or (integer -1 1)
+ unsigned-byte)
+ '(or (rational -1 7)
+ unsigned-byte
+ (integer -1 1))) => NIL,T
+ An analogous problem with SINGLE-FLOAT and REAL types was fixed in
+ sbcl-0.6.11.22, but some peculiarites of the RATIO type make it
+ awkward to generalize the fix to INTEGER and RATIONAL. It's not
+ clear what's the best fix. (See the "bug in type handling" discussion
+ on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
+
+93:
+ In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
+ src/cold/shared.lisp doesn't correctly translate the
+ interpreted function
+ (defun in-host-compilation-mode (fn)
+ (let ((*features* (cons :sb-xc-host *features*))
+ ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
+ ;; base-target-features.lisp-expr:
+ (*shebang-features* (set-difference *shebang-features*
+ '(:sb-propagate-float-type
+ :sb-propagate-fun-type))))
+ (with-additional-nickname ("SB-XC" "SB!XC")
+ (funcall fn))))
+ No error is reported by the compiler, but when the function is executed,
+ it causes an error
+ TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
+ (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
+ :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
+
+94a:
+ Inconsistencies between derived and declared VALUES return types for
+ DEFUN aren't checked very well. E.g. the logic which successfully
+ catches problems like
+ (declaim (ftype (function (fixnum) float) foo))
+ (defun foo (x)
+ (declare (type integer x))
+ (values x)) ; wrong return type, detected, gives warning, good!
+ fails to catch
+ (declaim (ftype (function (t) (values t t)) bar))
+ (defun bar (x)
+ (values x)) ; wrong number of return values, no warning, bad!
+ The cause of this is seems to be that (1) the internal function
+ VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
+ arguments symmetrically, and (2) when the type checking code was
+ written back when when SBCL's code was still CMU CL, the intent
+ was that this case
+ (declaim (ftype (function (t) t) bar))
+ (defun bar (x)
+ (values x x)) ; wrong number of return values; should give warning?
+ not be warned for, because a two-valued return value is considered
+ to be compatible with callers who expects a single value to be
+ returned. That intent is probably not appropriate for modern ANSI
+ Common Lisp, but fixing this might be complicated because of other
+ divergences between auld-style and new-style handling of
+ multiple-VALUES types. (Some issues related to this were discussed
+ on cmucl-imp at some length sometime in 2000.)
+
+95:
+ The facility for dumping a running Lisp image to disk gets confused
+ when run without the PURIFY option, and creates an unnecessarily large
+ core file (apparently representing memory usage up to the previous
+ high-water mark). Moreover, when the file is loaded, it confuses the
+ GC, so that thereafter memory usage can never be reduced below that
+ level.
+
+96:
+ The TRACE facility can't be used on some kinds of functions.
+ (Basically, the breakpoint facility was incompletely implemented
+ in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
+
+98:
+ In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
+ CL), out-of-line structure slot setters are horribly inefficient
+ whenever the type of the slot is declared, because out-of-line
+ structure slot setters are implemented as closures to save space,
+ so the compiler doesn't compile the type test into code, but
+ instead just saves the type in a lexical closure and interprets it
+ at runtime.
+ A proper solution involves deciding whether it's really worth
+ saving space by implementing structure slot accessors as closures.
+ (If it's not worth it, the problem vanishes automatically. If it
+ is worth it, there are hacks we could use to force type tests to
+ be compiled anyway, and even shared. E.g. we could implement
+ an EQUAL hash table mapping from types to compiled type tests,
+ and save the appropriate compiled type test as part of each lexical
+ closure; or we could make the lexical closures be placeholders
+ which overwrite their old definition as a lexical closure with
+ a new compiled definition the first time that they're called.)
+ As a workaround for the problem, #'(SETF FOO) expressions can
+ be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+(defmacro efficient-setf-function (place-function-name)
+ (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
+ ;; a workaround for the problem, encouraging the
+ ;; inline expansion of the structure accessor, so
+ ;; that the compiler can optimize its type test
+ (let ((new-value (gensym "NEW-VALUE-"))
+ (structure-value (gensym "STRUCTURE-VALUE-")))
+ `(lambda (,new-value ,structure-value)
+ (setf (,place-function-name ,structure-value)
+ ,new-value))))
+ ;; no problem, can just use the ordinary expansion
+ `(function (setf ,place-function-name))))
+
+99:
+ DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from
+ (let ((*print-circle* t)) (describe (make-hash-table)))
+ is weird,
+ #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
+ Its SIZE is 16.
+ Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
+ It holds 0 key/value pairs.
+ where the ". (EQL)" and ". (1.0)" substrings are screwups.
+ (This is likely a pretty-printer problem which happens to
+ be exercised by DESCRIBE, not actually a DESCRIBE problem.)
+
+100:
+ There's apparently a bug in CEILING optimization which caused
+ Douglas Crosher to patch the CMU CL version. Martin Atzmueller
+ applied the patches to SBCL and they didn't seem to cause problems
+ (as reported sbcl-devel 2001-05-04). However, since the patches
+ modify nontrivial code which was apparently written incorrectly
+ the first time around, until regression tests are written I'm not
+ comfortable merging the patches in the CVS version of SBCL.
+
+102:
+ As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
+ requires that SYMBOL-MACROLET refuse to rebind special variables,
+ but SBCL doesn't do this. (Also as reported by AL in the same
+ message, SBCL depended on this nonconforming behavior to build
+ itself, because of the way that **CURRENT-SEGMENT** was implemented.
+ As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
+ has been fixed, but the nonconforming behavior remains.)
+
+104:
+ (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
+ incorrectly:
+ DEF-ALIEN-TYPE is
+ an external symbol
+ in #<PACKAGE "SB-ALIEN">.
+ Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
+ Macro arguments: (#:whole-470 #:environment-471)
+ On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
+ /usr/stuff/sbcl/src/code/host-alieneval.lisp
+ Created: Monday, March 12, 2001 07:47:43 AM CST
+
+105:
+ (DESCRIBE 'STREAM-READ-BYTE)
+
+106:
+ (reported by Eric Marsden on cmucl-imp 2001-06-15)
+ (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
+ as bug 50e)
+
+108:
+ (TIME (ROOM T)) reports more than 200 Mbytes consed even for
+ a clean, just-started SBCL system. And it seems to be right:
+ (ROOM T) can bring a small computer to its knees for a *long*
+ time trying to GC afterwards. Surely there's some more economical
+ way to implement (ROOM T).
+
+109:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ ;;; This file fails to compile.
+ ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
+ (in-package :cl-user)
+ (defun tst2 ()
+ (labels
+ ((eff (&key trouble)
+ (eff)
+ ;; nil
+ ;; Uncomment and it works
+ ))
+ (eff)))
+ In SBCL 0.6.12.42, the problem is
+ internal error, failed AVER:
+ "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
+ (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
+
+110:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ ;;; The compiler is flushing the argument type test, and the default
+ ;;; case in the cond, so that calling with say a fixnum 0 causes a
+ ;;; SIGBUS.
+ (declaim (optimize (safety 2) (speed 3)))
+ (defun tst (x)
+ (declare (type (or string stream) x))
+ (cond ((typep x 'string) 'string)
+ ((typep x 'stream) 'stream)
+ (t
+ 'none)))
+ The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
+ (not the SIGBUS reported in the comment) but that's broken too;
+ type declarations are supposed to be treated as assertions unless
+ SAFETY 0, so we should be getting a TYPE-ERROR.
+
+111:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; Produces an assertion failures when compiled.
+ (defun foo (z)
+ (declare (type (or (function (t) t) null) z))
+ (let ((z (or z #'identity)))
+ (declare (type (function (t) t) z))
+ (funcall z 1)))
+ The error in sbcl-0.6.12.42 is
+ internal error, failed AVER:
+ "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
+
+112:
+ reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
+ collection; apparently originally reported by Bruno Haible
+ (in-package :cl-user)
+ ;;; From: Bruno Haible
+ ;;; Subject: scope of SPECIAL declarations
+ ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
+ ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
+ ;;; 1.4.0 cvs".
+ (let ((x 0))
+ (declare (special x))
+ (let ((x 1))
+ (let ((y x))
+ (declare (special x)) y)))
+ ;;; Gives: 0 (this should return 1 according to CLHS)
+ (let ((x 0))
+ (declare (special x))
+ (let ((x 1))
+ (let ((y x) (x 5))
+ (declare (special x)) y)))
+ ;;; Gives: 1 (correct).
+ The reported results match what we get from the interpreter
+ in sbcl-0.6.12.42.
+
+113:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; From: David Gadbois <gadbois@cyc.com>
+ ;;;
+ ;;; Logical pathnames aren't externalizable.
+ ;;; Test case:
+ (let ((tempfile "/tmp/test.lisp"))
+ (setf (logical-pathname-translations "XXX")
+ '(("XXX:**;*.*" "/tmp/**/*.*")))
+ (with-open-file (out tempfile :direction :output)
+ (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
+ (compile-file tempfile))
+ The error message in sbcl-0.6.12.42 is
+ ; caught ERROR:
+ ; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
+ ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
+
+115:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; The following invokes a compiler error.
+ (declaim (optimize (speed 2) (debug 3)))
+ (defun tst ()
+ (flet ((m1 ()
+ (unwind-protect nil)))
+ (if (catch nil)
+ (m1)
+ (m1))))
+ The error message in sbcl-0.6.12.42 is
+ internal error, failed AVER:
+ "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
+
+117:
+ When the compiler inline expands functions, it may be that different
+ kinds of return values are generated from different code branches.
+ E.g. an inline expansion of POSITION generates integer results
+ from one branch, and NIL results from another. When that inline
+ expansion is used in a context where only one of those results
+ is acceptable, e.g.
+ (defun foo (x)
+ (aref *a1* (position x *a2*)))
+ and the compiler can't prove that the unacceptable branch is
+ never taken, then bogus type mismatch warnings can be generated.
+ If you need to suppress the type mismatch warnings, you can
+ suppress the inline expansion,
+ (defun foo (x)
+ #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
+ (aref *a1* (position x *a2*)))
+ or, sometimes, suppress them by declaring the result to be of an
+ appropriate type,
+ (defun foo (x)
+ (aref *a1* (the integer (position x *a2*))))
+
+ This is not a new compiler problem in 0.7.0, but the new compiler
+ transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
+ more conspicuous. If you don't need performance from these functions,
+ and the bogus warnings are a nuisance for you, you can return to
+ your pre-0.7.0 state of grace with
+ #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
+
+118:
+ as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
+ (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
+ (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
+ when of course it should be NIL. (He says it only fails for X86,
+ not SPARC; dunno about Alpha.)
+
+ Also, "the same problem exists for LONG-FLOAT-EPSILON,
+ DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
+ for the -negative- the + is replaced by a - in the test)."
+
+ Raymond Toy comments that this is tricky on the X86 since its FPU
+ uses 80-bit precision internally.
+
+120a:
+ The compiler incorrectly figures the return type of
+ (DEFUN FOO (FRAME UP-FRAME)
+ (IF (OR (NOT FRAME)
+ T)
+ FRAME
+ "BAR"))
+ as NIL.
+
+ This problem exists in CMU CL 18c too. When I reported it on
+ cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
+ a partial explanation, but no fix has been found yet.
+
+120b:
+ Even in sbcl-0.pre7.x, which is supposed to be free of the old
+ non-ANSI behavior of treating the function return type inferred
+ from the current function definition as a declaration of the
+ return type from any function of that name, the return type of NIL
+ is attached to FOO in 120a above, and used to optimize code which
+ calls FOO.
+
+122:
+ There was some sort of screwup in handling of
+ (IF (NOT (IGNORE-ERRORS ..))). E.g.
+ (defun foo1i ()
+ (if (not (ignore-errors
+ (make-pathname :host "foo" :directory "!bla" :name "bar")))
+ (print "ok")
+ (error "notunlessnot")))
+ The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
+ printing "ok", but instead it's going to the ERROR. This problem
+ seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
+ 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
+ I reverted back to the old weird HANDLER-CASE code. However, I
+ think the problem looks like a compiler bug in handling RETURN-FROM,
+ so I left the MNA-patched code in HANDLER-CASE (suppressed with
+ #+NIL) and I'd like to go back to see whether this really is
+ a compiler bug before I delete this BUGS entry.
+
+123:
+ The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
+ (IN-PACKAGE :SB-KERNEL)
+ (TYPE= (SPECIFIER-TYPE '(VECTOR T))
+ (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
+ Then because of this, the compiler bogusly optimizes
+ (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
+ to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
+ NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
+ about type mismatches (probably harmlessly, another instance of bug 117);
+ and then cold init died with a segmentation fault.
+
+124:
+ As of version 0.pre7.14, SBCL's implementation of MACROLET makes
+ the entire lexical environment at the point of MACROLET available
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
+ access lexical variables (which are only defined at runtime).
+ It doesn't even issue a warning, which is bad.
+
+ The SBCL behavior arguably conforms to the ANSI spec (since the
+ spec says that the behavior is undefined, ergo anything conforms).
+ However, it would be better to issue a compile-time error.
+ Unfortunately I (WHN) don't see any simple way to detect this
+ condition in order to issue such an error, so for the meantime
+ SBCL just does this weird broken "conforming" thing.
+
+ The ANSI standard says, in the definition of the special operator
+ MACROLET,
+ The macro-expansion functions defined by MACROLET are defined
+ in the lexical environment in which the MACROLET form appears.
+ Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+ the local macro definitions in a MACROLET, but the consequences
+ are undefined if the local macro definitions reference any
+ local variable or function bindings that are visible in that
+ lexical environment.
+ Then it seems to contradict itself by giving the example
+ (defun foo (x flag)
+ (macrolet ((fudge (z)
+ ;The parameters x and flag are not accessible
+ ; at this point; a reference to flag would be to
+ ; the global variable of that name.
+ ` (if flag (* ,z ,z) ,z)))
+ ;The parameters x and flag are accessible here.
+ (+ x
+ (fudge x)
+ (fudge (+ x 1)))))
+ The comment "a reference to flag would be to the global variable
+ of the same name" sounds like good behavior for the system to have.
+ but actual specification quoted above says that the actual behavior
+ is undefined.
+
+125:
+ (as reported by Gabe Garza on cmucl-help 2001-09-21)
+ (defvar *tmp* 3)
+ (defun test-pred (x y)
+ (eq x y))
+ (defun test-case ()
+ (let* ((x *tmp*)
+ (func (lambda () x)))
+ (print (eq func func))
+ (print (test-pred func func))
+ (delete func (list func))))
+ Now calling (TEST-CASE) gives output
+ NIL
+ NIL
+ (#<FUNCTION {500A9EF9}>)
+ Evidently Python thinks of the lambda as a code transformation so
+ much that it forgets that it's also an object.
+
+126:
+ (fixed in 0.pre7.41)
+
+127:
+ The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
+ specifies a precedence rule for name collisions between slot accessors of
+ structure classes related by inheritance. As of 0.7.0, SBCL still
+ doesn't follow it.
+
+129:
+ insufficient syntax checking in MACROLET:
+ (defun foo (x)
+ (macrolet ((defmacro bar (z) `(+ z z)))
+ (bar x)))
+ shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+130:
+ reported by Alexey Dejneka on sbcl-devel 2001-11-03
+ (defun x (x)
+ "Return X if X is a non-negative integer."
+ (let ((step (lambda (%funcall)
+ (lambda (n)
+ (cond ((= n 0) 0)
+ (t (1+ (funcall %funcall (1- n)))))))))
+ (funcall
+ ((lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n))))
+ (lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n)))))
+ x)))
+ This function returns its argument. But after removing percents it
+ does not work: "Result of (1- n) is not a function".
+
+131:
+ As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
+ the CL:COMPILE function (which is based on the same %COMPILE
+ mechanism) get confused by
+(defun sxhash (x)
+ (labels ((sxhash-number (x)
+ (etypecase x
+ (fixnum (sxhash x)) ; through DEFTRANSFORM
+ (integer (sb!bignum:sxhash-bignum x))
+ (single-float (sxhash x)) ; through DEFTRANSFORM
+ (double-float (sxhash x)) ; through DEFTRANSFORM
+ #!+long-float (long-float (error "stub: no LONG-FLOAT"))
+ (ratio (let ((result 127810327))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (numerator x)))
+ (mixf result (sxhash-number (denominator x)))
+ result))
+ (complex (let ((result 535698211))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (realpart x)))
+ (mixf result (sxhash-number (imagpart x)))
+ result))))
+ (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
+ (declare (type index depthoid))
+ (typecase x
+ (list
+ (if (plusp depthoid)
+ (mix (sxhash-recurse (car x) (1- depthoid))
+ (sxhash-recurse (cdr x) (1- depthoid)))
+ 261835505))
+ (instance
+ (if (typep x 'structure-object)
+ (logxor 422371266
+ (sxhash ; through DEFTRANSFORM
+ (class-name (layout-class (%instance-layout x)))))
+ 309518995))
+ (symbol (sxhash x)) ; through DEFTRANSFORM
+ (number (sxhash-number x))
+ (array
+ (typecase x
+ (simple-string (sxhash x)) ; through DEFTRANSFORM
+ (string (%sxhash-substring x))
+ (bit-vector (let ((result 410823708))
+ (declare (type fixnum result))
+ (dotimes (i (min depthoid (length x)))
+ (mixf result (aref x i)))
+ result))
+ (t (logxor 191020317 (sxhash (array-rank x))))))
+ (character
+ (logxor 72185131
+ (sxhash (char-code x)))) ; through DEFTRANSFORM
+ (t 42))))
+ (sxhash-recurse x)))
+ complaining "function called with two arguments, but wants exactly
+ one" about SXHASH-RECURSE. (This might not be strictly a new bug,
+ since IIRC post-fork CMU CL has also had problems with &OPTIONAL
+ arguments in FLET/LABELS: it might be an old Python bug which is
+ only exercised by the new arrangement of the SBCL compiler.)
+
+132:
+ Trying to compile
+ (DEFUN FOO () (CATCH 0 (PRINT 1331)))
+ gives an error
+ #<SB-C:TN '0!1> is not valid as the second argument to VOP:
+ SB-C:MAKE-CATCH-BLOCK,
+ since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
+ any of the SCs allowed by the operand restriction:
+ (SB-VM::DESCRIPTOR-REG)
+ The (CATCH 0 ...) construct is bad style (because of unportability
+ of EQ testing of numbers) but it is legal, and shouldn't cause an
+ internal compiler error. (This error occurs in sbcl-0.6.13 and in
+ 0.pre7.86.flaky7.14.)
+
+133:
+ Trying to compile something like
+ (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
+ (code-obj sb!c-call:unsigned-long)
+ (pc-offset sb!c-call:int)
+ (old-inst sb!c-call:unsigned-long))
+ in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
+ cannot use values types here
+ probably because the SB-C-CALL:VOID type gets translated to (VALUES).
+ It should be valid to use VOID for a function return type, so perhaps
+ instead of calling SPECIFIER-TYPE (which excludes all VALUES types
+ automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
+ types manually, allowing the special case (VALUES) but still excluding
+ all more-complex VALUES types.
+
+135:
+ Ideally, uninterning a symbol would allow it, and its associated
+ FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
+ at least as of sbcl-0.7.0, this isn't the case. Information about
+ FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
+ essentially in ordinary (non-weak) hash tables keyed by symbols.
+ Thus, once a system has an entry in this system, it tends to live
+ forever, even when it is uninterned and all other references to it
+ are lost.
+
+136:
+ (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
+ (defmethod foo ((x integer))
+ x)
+ (defmethod foo :around ((x integer))
+ (let ((x (1+ x)))
+ (call-next-method)))
+ Now (FOO 3) should return 3, but instead it returns 4.
+
+137:
+ (SB-DEBUG:BACKTRACE) output should start with something
+ including the name BACKTRACE, not (as in 0.pre7.88)
+ just "0: (\"hairy arg processor\" ...)". Until about
+ sbcl-0.pre7.109, the names in BACKTRACE were all screwed
+ up compared to the nice useful names in sbcl-0.6.13.
+ Around sbcl-0.pre7.109, they were mostly fixed by using
+ NAMED-LAMBDA to implement DEFUN. However, there are still
+ some screwups left, e.g. as of sbcl-0.pre7.109, there are
+ still some functions named "hairy arg processor" and
+ "SB-INT:&MORE processor".
+
+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
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.
+(Now that the IR1 interpreter has gone away, these should be
+relatively straightforward to fix.)
IR1-4:
The system accepts DECLAIM in most places where DECLARE would be
EVAL-WHEN is rewritten, which won't happen until after the IR1
interpreter is gone, the system's notion of what's a top-level form
and what's not will remain too confused to fix this problem.]
+
+IR1-6:
+ (another wishlist thing..) Reimplement DEFMACRO to be basically
+ like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
projects / sbcl.git / blobdiff