X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=f1e41363fc77b7fc7da410eafef587b683be777a;hp=c296e96949128c33140e1fe5afb2d4e83be7cd38;hpb=3aba91516068375e01ffec0d19bf8cbe85feb828;p=sbcl.git diff --git a/BUGS b/BUGS index c296e96..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,806 +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 please 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 -KNOWN PORT-SPECIFIC BUGS +and the bug will be checked and added to Launchpad by SBCL maintainers. -The breakpoint-based TRACE facility doesn't work properly in the -OpenBSD port of sbcl-0.6.7. +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. -KNOWN BUGS - -(There is also some information on bugs in the manual page and in the -TODO file. Eventually more such information may move here.) - -* 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.) - -* 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). - -* COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -* DEFSTRUCT should almost certainly overwrite the old LAYOUT information - instead of just punting when a contradictory structure definition - is loaded. - -* 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.) - -* It should cause a STYLE-WARNING, not a WARNING, when the system ignores - an FTYPE proclamation for a slot accessor. - -* Missing ordinary arguments in a macro call aren't reported when the - macro lambda list contains &KEY: - (DEFMACRO FOO (BAR &KEY) BAR) => FOO - (FOO) => NIL - Also in DESTRUCTURING-BIND: - (DESTRUCTURING-BIND (X Y &REST REST) '(1) (VECTOR X Y REST)) - => #(1 NIL NIL) - Also with &REST lists: - (DEFMACRO FOO (BAR &REST REST) BAR) => FOO - (FOO) => NIL - -* 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.) - -* 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 - -* 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. - -* 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. - -* 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.) - -* 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.. - -* 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) - -* 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.) - -* 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. - -* 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.. - -* The message "The top of the stack was encountered." from the debugger - is not helpful when I type "FRAME 0" -- I know I'm going to the top - of the stack. - -* (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.) - -* The ANSI spec says that CONS can be a compound type spec, e.g. - (CONS FIXNUM REAL). SBCL doesn't support this. - -* 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 - -* 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)))))) - -* (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. " - -* 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)) - -* 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" - -* 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 - -* 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. - -* 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, - -* The print system doesn't conform to ANSI - "22.1.3.3.1 Package Prefixes for Symbols" for keywords printed when - *PACKAGE* is the KEYWORD package. - - from a message by Ray Toy on CMU CL mailing list Fri, 28 Apr 2000: - -In a discussion on comp.lang.lisp, the following code was given (by -Erik Naggum): - -(let ((*package* (find-package :keyword))) - (write-to-string object :readably t)) - -If OBJECT is a keyword, CMUCL prints out the keyword, but without a -colon. Hence, it's not readable, as requested. - -I think the following patch will make this work as expected. The -patch just basically checks for the keyword package first before -checking the current package. - -Ray - ---- ../cmucl-18c/src/code/print.lisp Wed Dec 8 14:33:47 1999 -+++ ../cmucl-18c/new/code/print.lisp Fri Apr 28 09:21:29 2000 -@@ -605,12 +605,12 @@ - (let ((package (symbol-package object)) - (name (symbol-name object))) - (cond -- ;; If the symbol's home package is the current one, then a -- ;; prefix is never necessary. -- ((eq package *package*)) - ;; If the symbol is in the keyword package, output a colon. - ((eq package *keyword-package*) - (write-char #\: stream)) -+ ;; If the symbol's home package is the current one, then a -+ ;; prefix is never necessary. -+ ((eq package *package*)) - ;; Uninterned symbols print with a leading #:. - ((null package) - (when (or *print-gensym* *print-readably*) - -* 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 - -# - -* 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. - -* 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. - -* 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. - -* There seems to be some sort of bug in the interaction of the - normal compiler, the byte compiler, and type predicates. - Compiling and loading this file - (IN-PACKAGE :CL-USER) - (DEFSTRUCT FOO A B) - (PROGN - (DECLAIM (FTYPE (FUNCTION (FOO) FOO) FOO-BAR)) - (DECLAIM (INLINE FOO-BAR)) - (DEFUN FOO-BAR (FOO) - (DECLARE (TYPE FOO FOO)) - (LET ((RESULT2605 (BLOCK FOO-BAR (PROGN (THE FOO (FOO-A FOO)))))) - (UNLESS (TYPEP RESULT2605 'FOO) - (LOCALLY (ERROR "OOPS"))) - (THE FOO RESULT2605))) - 'FOO-BAR) - (DEFPARAMETER *FOO* (MAKE-FOO :A (MAKE-FOO))) - (UNLESS (EQ *PRINT-LEVEL* 133) - (DEFUN CK? () - (LABELS ((FLOOD () - (WHEN (TYPEP *X* 'FOO) - (FOO-BAR *Y*)))))) - (PRINT 11) - (PRINT (FOO-BAR *FOO*)) - (PRINT 12)) - in sbcl-0.6.5 (or also in CMU CL 18b for FreeBSD) gives a call - to the undefined function SB-C::%INSTANCE-TYPEP. %INSTANCE-TYPEP - is not defined as a function because it's supposed to - be transformed away. My guess is what's happening is that - the mixture of toplevel and non-toplevel stuff and inlining - is confusing the system into compiling an %INSTANCE-TYPEP - form into byte code, where the DEFTRANSFORM which is supposed - to get rid of such forms is not effective. - -* 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. - -* 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. - -* 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. - -* 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. - -* 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. - -* 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? - -* 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.) - -* 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. - -* 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. - -* 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) - -* 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. - -* 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. - -* 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. - -* 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. - -* (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. - -* 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. - -* a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - * (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined. - Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others - aren't found. - * 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. - * 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. - * (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. - -* type safety errors reported by Peter Van Eynde July 25, 2000: - * (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. - * 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. - * (COERCE 'AND 'FUNCTION) returns something related to - (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - * ELT signals SIMPLE-ERROR if its index argument - isn't a valid index for its sequence argument, but should - signal TYPE-ERROR instead. - * FILE-LENGTH is supposed to signal a type error when its - argument is not a stream associated with a file, but doesn't. - * (FLOAT-RADIX 2/3) should signal an error instead of - returning 2. - * (LOAD "*.lsp") should signal FILE-ERROR. - * (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) - should signal TYPE-ERROR. - * 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. - * (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. - * 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"). - -* DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - * (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and doesn't. - * (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should - signal a PROGRAM-ERROR, and doesn't. - * (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. - * (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead - causes a COMPILER-ERROR. - -* SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - * (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal - PROGRAM-ERROR, but SBCL accepts it instead. - * SYMBOL-MACROLET should refuse to bind something which is - declared as a global variable, signalling PROGRAM-ERROR. - * SYMBOL-MACROLET should signal PROGRAM-ERROR if something - it binds is declared SPECIAL inside. - -* LOOP bugs reported by Peter Van Eynde July 25, 2000: - * (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. - * 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. - -* type system errors reported by Peter Van Eynde July 25, 2000: - * (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - * (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. - * (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. - * 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. - * (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. - * The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. - * 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. - -* miscellaneous errors reported by Peter Van Eynde July 25, 2000: - * (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. - * READ should probably return READER-ERROR, not the bare - arithmetic error, when input a la "1/0" or "1e1000" causes - an arithmetic error. - * 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.) - * (BUTLAST NIL) should return NIL. (This appears to be a compiler - bug, since the definition of BUTLAST, when interpreted, does - give (BUTLAST NIL)=>NIL.) - -* 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. - -* The bug discussed on the cmucl-imp@cons.org mailing list ca. 5 September, - simplified by Douglas Crosher down to - (defun tickle-bug () - (labels ((fun1 () - (fun2)) - (fun2 () - (when nil - (tagbody - tag - (fun2) - (go tag))) - (when nil - (tagbody - tag - (fun1) - (go tag))))) - (fun1) - nil)) - causes the same problem on SBCL: compiling it fails with - :LET fell through ECASE expression. - Very likely the patch discussed there is appropriate for SBCL - as well, but I don't understand it, so I didn't apply it. - -* The implementation of #'+ returns its single argument without - type checking, e.g. (+ "illegal") => "illegal". - -* 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. - -* 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. - -* In sbcl-0.6.7, the compiler accepted a bogus declaration - (TYPE INDEX LENGTH) in the definition of BUTLAST, and then died - with infinite regress of errors when the BUTLAST function was - executed with a LIST=NIL which would cause LENGTH to be -1. - I fixed the bogus declaration, but I should come back and see - whether the system's inability to recover from the bogus declaration - (by signalling a TYPE-ERROR and dropping into the debugger) was - a compiler problem which remains to be fixed, or one of the - unrelated infinite-regress-errors problems, many related to - revised signal handling, which were fixed around the same time. - -* Even when FINISH-OUTPUT is called, the system doesn't in general - flush the last line of output unless it's terminated by a newline. - (This is particularly annoying because several Lisp functions like - PRINT *precede* their output with a newline, instead of following - it with a newline.) - -* (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL \ No newline at end of file +Refer to User Manual for more details.