the program loops endlessly instead of printing the object.
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-At some point, the 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 go away automatically. Until then,
-they'll probably remain, since they're not considered urgent.
-
-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
+NOTES:
+There is also some information on bugs in the manual page and
+in the TODO file. Eventually more such information may move here.
-OTHER KNOWN BUGS:
+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).
-(There is also some information on bugs in the manual page and in the
-TODO file. Eventually more such information may move here.)
-1:
- Failure in initialization files is not handled gracefully -- it's
- a throw to TOP-LEVEL-CATCHER, which is not caught until we enter
- TOPLEVEL-REPL. Code should be added to catch such THROWs even when
- we're not in TOPLEVEL-REPL and do *something* with them (probably
- complaining about an error outside TOPLEVEL-REPL, perhaps printing
- a BACKTRACE, then terminating execution of SBCL).
+KNOWN BUGS OF NO SPECIAL CLASS:
2:
- DEFSTRUCT should almost certainly overwrite the old LAYOUT information
+ DEFSTRUCT almost certainly should overwrite the old LAYOUT information
instead of just punting when a contradictory structure definition
- is loaded.
+ 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:
- It should cause a STYLE-WARNING, not a full WARNING, when a structure
- slot default value does not match the declared structure slot type.
- (The current behavior is consistent with SBCL's behavior elsewhere,
- and would not be a problem, except that the other behavior is
- specifically required by the ANSI spec.)
-
-4:
- It should cause a note, not a WARNING, when the system ignores
- an FTYPE proclamation for a slot accessor.
-
-5:
- Error reporting on various stream-requiring operations is not
- very good when the stream argument has the wrong type, because
- the operation tries to fall through to Gray stream code, and then
- dies because it's undefined. E.g.
- (PRINT-UNREADABLE-OBJECT (*STANDARD-OUTPUT* 1))
- gives the error message
- error in SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
- The function SB-IMPL::STREAM-WRITE-STRING is undefined.
- It would be more useful and correct to signal a TYPE-ERROR:
- not a STREAM: 1
- (It wouldn't be terribly difficult to write stubs for all the
- Gray stream functions that the old CMU CL code expects, with
- each stub just raising the appropriate TYPE-ERROR.)
+ ANSI specifies that a type mismatch in a structure slot
+ initialization value should not cause a warning.
+WORKAROUND:
+ This one might not be fixed for a while because while we're big
+ believers in ANSI compatibility and all, (1) there's no obvious
+ simple way to do it (short of disabling all warnings for type
+ mismatches everywhere), and (2) there's a good portable
+ workaround, and (3) by their own reasoning, it looks as though
+ ANSI may have gotten it wrong. ANSI justifies this specification
+ by saying
+ The restriction against issuing a warning for type mismatches
+ between a slot-initform and the corresponding slot's :TYPE
+ option is necessary because a slot-initform must be specified
+ in order to specify slot options; in some cases, no suitable
+ default may exist.
+ However, in SBCL (as in CMU CL or, for that matter, any compiler
+ which really understands Common Lisp types) a suitable default
+ does exist, in all cases, because the compiler understands the
+ concept of functions which never return (i.e. has return type NIL).
+ Thus, as a portable workaround, you can use a call to some
+ known-never-to-return function as the default. E.g.
+ (DEFSTRUCT FOO
+ (BAR (ERROR "missing :BAR argument")
+ :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
+ or
+ (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
+ (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
+ (ERROR "missing required argument"))
+ (DEFSTRUCT FOO
+ (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
+ (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
+ (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
+ Such code should compile without complaint and work correctly either
+ on SBCL or on any other completely compliant Common Lisp system.
6:
bogus warnings about undefined functions for magic functions like
SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
- like src/code/float.lisp
+ like src/code/float.lisp. Fixing this will probably require
+ straightening out enough bootstrap consistency issues that
+ the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
+ Instead, the cross-compiler runs in a slightly flaky state
+ which is sane enough to compile SBCL itself, but which is
+ also unstable in several ways, including its inability
+ to really grok function declarations.
7:
- The "byte compiling top-level form:" output ought to be condensed.
+ 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.
-
-8:
- Compiling a file containing the erroneous program
- (DEFSTRUCT FOO
- A
- B)
- (DEFSTRUCT (BAR (:INCLUDE FOO))
- A
- B)
- gives only the not-very-useful message
- caught ERROR:
- (during macroexpansion)
- Condition PROGRAM-ERROR was signalled.
- (The specific message which says that the problem was duplicate
- slot names gets lost.)
-
-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.
-
-17:
- from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000:
-I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical
-pathname, the type of the corresponding compiled file is X86F:
- * (compile-file "/home/paolo/lisp/tools/foo")
- Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm.
- Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
- Converted SQUARE.
- Compiling DEFUN SQUARE:
- Byte Compiling Top-Level Form:
- /home/paolo/lisp/tools/foo.x86f written.
- Compilation finished in 0:00:00.
- #p"/home/paolo/lisp/tools/foo.x86f"
- NIL
- NIL
-But when the function is called with a logical pathname, the file type
-becomes FASL:
- * (compile-file "tools:foo")
- Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm.
- Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
- Converted SQUARE.
- Compiling DEFUN SQUARE:
- Byte Compiling Top-Level Form:
- TOOLS:FOO.FASL written.
- Compilation finished in 0:00:00.
- #p"/home/paolo/lisp/tools/foo.fasl"
- NIL
- NIL
-
-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. "
DTC's recommended workaround from the mailing list 3 Mar 2000:
(setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
-21:
- There's probably a bug in the compiler handling of special variables
- in closures, inherited from the CMU CL code, as reported on the
- CMU CL mailing list. There's a patch for this on the CMU CL
- mailing list too:
- Message-ID: <38C8E188.A1E38B5E@jeack.com.au>
- Date: Fri, 10 Mar 2000 22:50:32 +1100
- From: "Douglas T. Crosher" <dtc@jeack.com.au>
-
22:
The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
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.
-28:
- 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.
-
-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.
-
-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.
(FAIL 12)
then requesting a BACKTRACE at the debugger prompt gives no information
about where in the user program the problem occurred.
+
+62:
+ The compiler is supposed to do type inference well enough that
+ the declaration in
+ (TYPECASE X
+ ((SIMPLE-ARRAY SINGLE-FLOAT)
+ (LOCALLY
+ (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
+ ..))
+ ..)
+ is redundant. However, as reported by Juan Jose Garcia Ripoll for
+ CMU CL, it sometimes doesn't. Adding declarations is a pretty good
+ workaround for the problem for now, but can't be done by the TYPECASE
+ macros themselves, since it's too hard for the macro to detect
+ assignments to the variable within the clause.
+ Note: The compiler *is* smart enough to do the type inference in
+ many cases. This case, derived from a couple of MACROEXPAND-1
+ calls on Ripoll's original test case,
+ (DEFUN NEGMAT (A)
+ (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
+ (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
+ (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
+ (LET ((I 0) (G2554 LENGTH))
+ (DECLARE (TYPE REAL G2554) (TYPE REAL I))
+ (TAGBODY
+ SB-LOOP::NEXT-LOOP
+ (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
+ (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
+ (GO SB-LOOP::NEXT-LOOP)
+ SB-LOOP::END-LOOP))))))
+ demonstrates the problem; but the problem goes away if the TAGBODY
+ and GO forms are removed (leaving the SETF in ordinary, non-looping
+ code), or if the TAGBODY and GO forms are retained, but the
+ assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
+
+63:
+ Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
+ I am looking into this problem that showed up on the cmucl-help
+ list. It seems to me that the "implementation specific environment
+ hacking functions" found in pcl/walker.lisp are completely messed
+ up. The good thing is that they appear to be barely used within
+ PCL and the munged environment object is passed to cmucl only
+ in calls to macroexpand-1, which is probably why this case fails.
+ SBCL uses essentially the same code, so if the environment hacking
+ is screwed up, it affects us too.
+
+64:
+ Using the pretty-printer from the command prompt gives funny
+ results, apparently because the pretty-printer doesn't know
+ about user's command input, including the user's carriage return
+ that the user, and therefore the pretty-printer thinks that
+ the new output block should start indented 2 or more characters
+ rightward of the correct location.
+
+65:
+ (probably related to bug #70; maybe related to bug #109)
+ As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
+ compiling this file
+(in-package "CL-USER")
+(defun equal-terms (termx termy)
+ (labels
+ ((alpha-equal-bound-term-lists (listx listy)
+ (or (and (null listx) (null listy))
+ (and listx listy
+ (let ((bindings-x (bindings-of-bound-term (car listx)))
+ (bindings-y (bindings-of-bound-term (car listy))))
+ (if (and (null bindings-x) (null bindings-y))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (and (= (length bindings-x) (length bindings-y))
+ (prog2
+ (enter-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (exit-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))))))
+ (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
+
+ (alpha-equal-terms (termx termy)
+ (if (and (variable-p termx)
+ (variable-p termy))
+ (equal-bindings (id-of-variable-term termx)
+ (id-of-variable-term termy))
+ (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
+ (alpha-equal-bound-term-lists (bound-terms-of-term termx)
+ (bound-terms-of-term termy))))))
+
+ (or (eq termx termy)
+ (and termx termy
+ (with-variable-invocation (alpha-equal-terms termx termy))))))
+ causes an assertion failure
+ The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
+ (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
+
+ Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
+ case with the same problem:
+(defun parse-fssp-alignment ()
+ ;; Given an FSSP alignment file named by the argument . . .
+ (labels ((get-fssp-char ()
+ (get-fssp-char))
+ (read-fssp-char ()
+ (get-fssp-char)))
+ ;; Stub body, enough to tickle the bug.
+ (list (read-fssp-char)
+ (read-fssp-char))))
+
+66:
+ ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
+ a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
+ (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
+ This also leads to funny behavior when derived type specifiers
+ are used, as originally reported by Milan Zamazal for CMU CL (on the
+ Debian bugs mailing list (?) 2000-02-27), then reported by Martin
+ Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
+ (DEFTYPE FOO () 'SIMPLE-ARRAY)
+ (CONCATENATE 'FOO #(1 2) '(3))
+ => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
+ sequence functions.
+ The derived type specifier FOO should act the same way as the
+ built-in type SIMPLE-ARRAY here, but it doesn't. That problem
+ doesn't seem to exist for sequence types:
+ (DEFTYPE BAR () 'SIMPLE-VECTOR)
+ (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
+
+67:
+ As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
+ and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
+ crashes SBCL. In general tracing anything which is used in the
+ implementation of TRACE is likely to have the same problem.
+
+68:
+ As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
+ SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
+ notably including all PCL instances. There's a limit to how much
+ SXHASH can do to return unique values for instances, but at least
+ it should probably look at the class name, the way that it does
+ for STRUCTURE-OBJECTs.
+
+69:
+ As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
+ > There remains one issue, that is a bug in SBCL:
+ > According to my interpretation of the spec, the ":" and "@" modifiers
+ > should appear _after_ the comma-seperated arguments.
+ > Well, SBCL (and CMUCL for that matter) accept
+ > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
+ > where the correct way (IMHO) should be
+ > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
+ Probably SBCL should stop accepting the "~:8D"-style format arguments,
+ or at least issue a warning.
+
+70:
+ (probably related to bug #65; maybe related to bug #109)
+ The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
+ forms. E.g.
+ (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
+ (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
+ (LET ((ITEM (FIRST SEQ)))
+ (COND ((NULL SEQ)
+ (VALUES NIL NIL))
+ ((FUNCALL TEST OBJ ITEM)
+ (VALUES VAL SEQ))
+ (T
+ (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
+ (FIND-ITEM ITEM SEQUENCE TEST)))
+ from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
+ causes sbcl-0.6.9 to fail with
+ error in function SB-KERNEL:ASSERT-ERROR:
+ The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
+ (SB-C::LAMBDA-TAIL-SET
+ (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
+
+71:
+ (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after
+ (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
+ the previous SPEED policy. This bug will probably get fixed in
+ 0.6.9.x in a general cleanup of optimization policy.
+
+72:
+ (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+75:
+ As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
+ ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
+ :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
+ WITH-OUTPUT-TO-STRING.
+
+78:
+ ANSI says in one place that type declarations can be abbreviated even
+ when the type name is not a symbol, e.g.
+ (DECLAIM ((VECTOR T) *FOOVECTOR*))
+ SBCL doesn't support this. But ANSI says in another place that this
+ isn't allowed. So it's not clear this is a bug after all. (See the
+ e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
+ and Pierre Mai.)
+
+79:
+ as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
+ The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
+ an easily guessable temporary filename in a way which might open
+ applications using LOAD-FOREIGN to hijacking by malicious users
+ on the same machine. Incantations for doing this safely are
+ floating around the net in various "how to write secure programs
+ despite Unix" documents, and it would be good to (1) fix this in
+ LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
+ files and make it share the same new safe logic.
+
+82:
+ Functions are assigned names based on the context in which they're
+ defined. This is less than ideal for the functions which are
+ used to implement CLOS methods. E.g. the output of
+ (DESCRIBE 'PRINT-OBJECT) lists functions like
+ #<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
+
+(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
+ accepted, without even issuing a warning. ANSI allows this, but since
+ it's fairly easy to mistype DECLAIM instead of DECLARE, and the
+ meaning is rather different, and it's unlikely that the user
+ has a good reason for doing DECLAIM not at top level, it would be
+ good to issue a STYLE-WARNING when this happens. A possible
+ fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
+ or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
+ [This is considered an IR1-interpreter-related bug because until
+ EVAL-WHEN is rewritten, which won't happen until after the IR1
+ interpreter is gone, the system's notion of what's a top-level form
+ and what's not will remain too confused to fix this problem.]
+
+IR1-6:
+ (another wishlist thing..) Reimplement DEFMACRO to be basically
+ like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
projects / sbcl.git / blobdiff