X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=f1e41363fc77b7fc7da410eafef587b683be777a;hp=0a80569a59ecc580b826eb4b24892c785024bab5;hpb=77360ee4a1f94c41b807be7ad0e8687199fceef1;p=sbcl.git diff --git a/BUGS b/BUGS index 0a80569..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,846 +1,17 @@ -REPORTING BUGS +SBCL uses Launchpad to track bugs. The bug database is available at: -Bugs can be reported on the help mailing list - sbcl-help@lists.sourceforge.net -or on the development mailing list - sbcl-devel@lists.sourceforge.net + https://bugs.launchpad.net/sbcl -Please include enough information in a bug report that someone reading -it can reproduce the problem, i.e. don't write - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug? -but instead - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when - I compile and load the file - (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y) - (LET ((*PRINT-LENGTH* 4)) - (PRINT X Y))))) - X Y) - then at the command line type - (MAKE-FOO) - the program loops endlessly instead of printing the object. +Reporting bugs there requires registering at Launchpad. However, bugs +can also be reported on the mailing list sbcl-bugs, which is +moderated but does _not_ require subscribing. Simply send email to + sbcl-bugs@lists.sourceforge.net -NOTES: +and the bug will be checked and added to Launchpad by SBCL maintainers. -There is also some information on bugs in the manual page and -in the TODO file. Eventually more such information may move here. +Historical note: before Launchpad was adopted this file contained a +list of currently open bugs. If you run into an SBCL bug number in the +range 1-431 inclusive, it refers to that list. -The gaps in the number sequence belong to old bugs which have been -fixed. - - -KNOWN BUGS OF NO SPECIAL CLASS: - -2: - DEFSTRUCT should almost certainly overwrite the old LAYOUT information - instead of just punting when a contradictory structure definition - is loaded. As it is, if you redefine DEFSTRUCTs in a way which - changes their layout, you probably have to rebuild your entire - program, even if you know or guess enough about the internals of - SBCL to wager that this (undefined in ANSI) operation would be safe. - -3: - 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.) - -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 - -7: - The "byte 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. - -10: - The way that the compiler munges types with arguments together - with types with no arguments (in e.g. TYPE-EXPAND) leads to - weirdness visible to the user: - (DEFTYPE FOO () 'FIXNUM) - (TYPEP 11 'FOO) => T - (TYPEP 11 '(FOO)) => T, which seems weird - (TYPEP 11 'FIXNUM) => T - (TYPEP 11 '(FIXNUM)) signals an error, as it should - The situation is complicated by the presence of Common Lisp types - like UNSIGNED-BYTE (which can either be used in list form or alone) - so I'm not 100% sure that the behavior above is actually illegal. - But I'm 90+% sure, and someday perhaps I'll be motivated to look it up.. - -11: - It would be nice if the - caught ERROR: - (during macroexpansion) - said what macroexpansion was at fault, e.g. - caught ERROR: - (during macroexpansion of IN-PACKAGE, - during macroexpansion of DEFFOO) - -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..) - (FORMAT NIL "~,1G" 1.4) => "1. " - (FORMAT NIL "~3,1G" 1.4) => "1. " - -20: - from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000: - (defclass ccc () ()) - (setf (find-class 'ccc1) (find-class 'ccc)) - (defmethod zut ((c ccc1)) 123) - DTC's recommended workaround from the mailing list 3 Mar 2000: - (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) - -22: - The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block", - says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used - inside "~<..~>" (without the colon modifier on the closing syntax). - However, SBCL doesn't do this: - * (FORMAT T "~" 12) - munge12egnum - NIL - -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 - -# - -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. - (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1))) - (DEFSTRUCT FOO A B) - (DEFUN BAR (X) - (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X)) - (WHEN (CONSP (AREF X 0)) - (PRINT (AREF X 0)))) - (BAR (VECTOR (MAKE-FOO :A 11 :B 12))) - prints - #S(FOO :A 11 :B 12) - in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for - all cases, e.g. the type assumption *is* checked if the array - elements are declared to be of some structure type instead of CONS. - -32: - The printer doesn't report closures very well. This is true in - CMU CL 18b as well: - (PRINT #'CLASS-NAME) - gives - # - It would be nice to make closures have a settable name slot, - and make things like DEFSTRUCT and FLET, which create closures, - set helpful values into this slot. - -33: - And as long as we're wishing, it would be awfully nice if INSPECT could - also report on closures, telling about the values of the bound variables. - -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 () ()) - # - * (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: - # - 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 FOO (X) - (COND ((> (FACTORIAL X) 1.0E6) - (FORMAT T "too big~%")) - ((INTEGERP X) - (FORMAT T "exactly ~S~%" (FACTORIAL X))) - (T - (FORMAT T "approximately ~S~%" (FACTORIAL X))))) - then executing - (FOO 1.5) - will cause the INTEGERP case to be selected, giving bogus output a la - exactly 1.33.. - This violates the "declarations are assertions" principle. - According to the ANSI spec, in the section "System Class FUNCTION", - this is a case of "lying to the compiler", but the lying is done - by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments, - not by the unexpectedly general definition of FACTORIAL. In any case, - "declarations are assertions" means that lying to the compiler should - cause an error to be signalled, and should not cause a bogus - result to be returned. Thus, the compiler should not assume - that arbitrary functions check their argument types. (It might - make sense to add another flag (CHECKED?) to DEFKNOWN to - identify functions which *do* check their argument types.) - -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. - -41: - TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in - (DEFTYPE INDEXOID () '(INTEGER 0 1000)) - (DEFUN FOO (X) - (DECLARE (TYPE INDEXOID X)) - (THE (VALUES INDEXOID) - (VALUES X))) - where the implementation of the type check in function FOO - includes a full call to %TYPEP. There are also some fundamental problems - with the interpretation of VALUES types (inherited from CMU CL, and - from the ANSI CL standard) as discussed on the cmucl-imp@cons.org - mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000. - -42: - The definitions of SIGCONTEXT-FLOAT-REGISTER and - %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not - supported on FreeBSD because the floating point state is not saved, - but at least as of FreeBSD 4.0, the floating point state *is* saved, - so they could be supported after all. Very likely - SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. - -43: - (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. - Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same - issue with 'union, 'and, 'or etc. So even though according to the - ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL - (and now SBCL) interpret them as legal types. - -44: - ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL. - CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing - list, and it is probably possible to use substantially the same - patches to add it to SBCL. - -45: - a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined. - Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others - aren't found. - b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and - should probably be 1.4012985e-45. In SBCL, - (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller - than LEAST-POSITIVE-SHORT-FLOAT. Similar problems - exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, - and LEAST-NEGATIVE-LONG-FLOAT. - c: Many expressions generate floating infinity: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. SBCL - generates the infinities instead, which may or may not be - conforming behavior, 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. - d: (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) - don't give the right behavior. - -46: - type safety errors reported by Peter Van Eynde July 25, 2000: - a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4))) - => #(A B C) - In general lengths of array type specifications aren't - checked by COERCE, so it fails when the spec is - (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever. - b: CONCATENATE has the same problem of not checking the length - of specified output array types. MAKE-SEQUENCE and MAP and - MERGE also have the same problem. - c: (COERCE 'AND 'FUNCTION) returns something related to - (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - 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. - h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) - should signal TYPE-ERROR. - i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can - be used for input and output as needed. It should fail with - TYPE-ERROR when handed e.g. the results of - MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in - the inappropriate positions, but doesn't. - j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8) - (QUOTE STRING))) - should probably signal an error instead of making a pathname with - a null byte in it. - k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - -47: - DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and - doesn't. - b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should - signal a PROGRAM-ERROR, and doesn't. - c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))), - and other DEFCLASS forms with duplicate specifications in their - slots, should signal a PROGRAM-ERROR, and doesn't. - d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead - causes a COMPILER-ERROR. - -48: - SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal - PROGRAM-ERROR, but SBCL accepts it instead. - b: SYMBOL-MACROLET should refuse to bind something which is - declared as a global variable, signalling PROGRAM-ERROR. - c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something - it binds is declared SPECIAL inside. - -49: - LOOP bugs reported by Peter Van Eynde July 25, 2000: - a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to - the definition of WITH clauses given in the ANSI spec, but - compiles and runs happily in SBCL. - b: a messy one involving package iteration: -interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)))) -Should be: (("blah" "blah2") ("blah2")) -SBCL: (("blah") ("blah2")) - * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I)) - doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause. - -50: - type system errors reported by Peter Van Eynde July 25, 2000: - a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. - c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. - d: In general, the system doesn't like '(INTEGER (0) (0)) -- it - blows up at the level of SPECIFIER-TYPE with - "Lower bound (0) is greater than upper bound (0)." Probably - SPECIFIER-TYPE should return NIL instead. - e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with - "Component type for Complex is not numeric: (EQL 0)." - This might be easy to fix; the type system already knows - that (SUBTYPEP '(EQL 0) 'NUMBER) is true. - f: The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. - g: The type system isn't all that smart about relationships - between hairy types, as shown in the type.erg test results, - e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL. - -51: - miscellaneous errors reported by Peter Van Eynde July 25, 2000: - a: (PROGN - (DEFGENERIC FOO02 (X)) - (DEFMETHOD FOO02 ((X NUMBER)) T) - (LET ((M (FIND-METHOD (FUNCTION FOO02) - NIL - (LIST (FIND-CLASS (QUOTE NUMBER)))))) - (REMOVE-METHOD (FUNCTION FOO02) M) - (DEFGENERIC FOO03 (X)) - (ADD-METHOD (FUNCTION FOO03) M))) - should give an error, but SBCL allows it. - b: READ should probably return READER-ERROR, not the bare - arithmetic error, when input a la "1/0" or "1e1000" causes - an arithmetic error. - -52: - It has been reported (e.g. by Peter Van Eynde) that there are - several metaobject protocol "errors". (In order to fix them, we might - need to document exactly what metaobject protocol specification - we're following -- the current code is just inherited from PCL.) - -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)) - (COMPILE 'FOO) -Error in function C::GET-LAMBDA-TO-COMPILE: - # 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). - -60: - The debugger LIST-LOCATIONS command doesn't work properly. - -61: - Compiling and loading - (DEFUN FAIL (X) (THROW 'FAIL-TAG X)) - (FAIL 12) - then requesting a BACKTRACE at the debugger prompt gives no information - about where in the user program the problem occurred. - -62: - The compiler is supposed to do type inference well enough that - the declaration in - (TYPECASE X - ((SIMPLE-ARRAY SINGLE-FLOAT) - (LOCALLY - (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X)) - ..)) - ..) - is redundant. However, as reported by Juan Jose Garcia Ripoll for - CMU CL, it sometimes doesn't. Adding declarations is a pretty good - workaround for the problem for now, but can't be done by the TYPECASE - macros themselves, since it's too hard for the macro to detect - assignments to the variable within the clause. - Note: The compiler *is* smart enough to do the type inference in - many cases. This case, derived from a couple of MACROEXPAND-1 - calls on Ripoll's original test case, - (DEFUN NEGMAT (A) - (DECLARE (OPTIMIZE SPEED (SAFETY 0))) - (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL - (LET ((LENGTH (ARRAY-TOTAL-SIZE A))) - (LET ((I 0) (G2554 LENGTH)) - (DECLARE (TYPE REAL G2554) (TYPE REAL I)) - (TAGBODY - SB-LOOP::NEXT-LOOP - (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP)) - (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I))) - (GO SB-LOOP::NEXT-LOOP) - SB-LOOP::END-LOOP)))))) - demonstrates the problem; but the problem goes away if the TAGBODY - and GO forms are removed (leaving the SETF in ordinary, non-looping - code), or if the TAGBODY and GO forms are retained, but the - assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)). - - -KNOWN BUGS RELATED TO THE IR1 INTERPRETER - -(Note: At some point, the pure interpreter (actually a semi-pure -interpreter aka "the IR1 interpreter") will probably go away, replaced -by constructs like - (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) -and at that time these bugs should either go away automatically or -become more tractable to fix. Until then, they'll probably remain, -since some of them aren't considered urgent, and the rest are too hard -to fix as long as so many special cases remain. After the IR1 -interpreter goes away is also the preferred time to start -systematically exterminating cases where debugging functionality -(backtrace, breakpoint, etc.) breaks down, since getting rid of the -IR1 interpreter will reduce the number of special cases we need to -support.) - -IR1-1: - The FUNCTION special operator doesn't check properly whether its - argument is a function name. E.g. (FUNCTION (X Y)) returns a value - instead of failing with an error. (Later attempting to funcall the - value does cause an error.) - -IR1-2: - COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -IR1-3: - Executing - (DEFVAR *SUPPRESS-P* T) - (EVAL '(UNLESS *SUPPRESS-P* - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (FORMAT T "surprise!")))) - prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be - rewritten from scratch to conform to the ANSI definition, abandoning - the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and - in the original CMU CL source, too). This should be easier to do -- - though still nontrivial -- once the various IR1 interpreter special - cases are gone. - -IR1-3a: - EVAL-WHEN's idea of what's a toplevel form is even more screwed up - than the example in IR1-3 would suggest, since COMPILE-FILE and - COMPILE both print both "right now!" messages when compiling the - following code, - (LAMBDA (X) - (COND (X - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "yes! right now!")) - "yes!") - (T - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "no! right now!")) - "no!"))) - and while EVAL doesn't print the "right now!" messages, the first - FUNCALL on the value returned by EVAL causes both of them to be printed. - -IR1-4: - 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.] +Refer to User Manual for more details.