X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=68cbee7b93df6dc0b501da71d5db4f41c0c63e83;hb=4fc9d21ae1d8a6a2f8ff70f589d5da103203de13;hp=395fbab001566d3d91df0949b7697039ead2f913;hpb=e240e076bc5bfa07a408a89d2e354e7ec9ff9341;p=sbcl.git diff --git a/BUGS b/BUGS index 395fbab..68cbee7 100644 --- a/BUGS +++ b/BUGS @@ -27,14 +27,15 @@ NOTES: There is also some information on bugs in the manual page and in the TODO file. Eventually more such information may move here. -The gaps in the number sequence belong to old bugs which have been -fixed. +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). 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. As it is, if you redefine DEFSTRUCTs in a way which changes their layout, you probably have to rebuild your entire @@ -42,56 +43,55 @@ KNOWN BUGS OF NO SPECIAL CLASS: 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. ANSI justifies this specification by saying + The restriction against issuing a warning for type mismatches + between a slot-initform and the corresponding slot's :TYPE + option is necessary because a slot-initform must be specified + in order to specify slot options; in some cases, no suitable + default may exist. + In SBCL, as in CMU CL (or, for that matter, any compiler which + really understands Common Lisp types) a suitable default does + exist, in all cases, because the compiler understands the concept + of functions which never return (i.e. has return type NIL, e.g. + ERROR). Thus, as a portable workaround, you can use a call to + some known-never-to-return function as the default. E.g. + (DEFSTRUCT FOO + (BAR (ERROR "missing :BAR argument") + :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF)) + or + (DECLAIM (FTYPE () NIL) MISSING-ARG) + (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing + (ERROR "missing required argument")) + (DEFSTRUCT FOO + (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) + (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) + (N-REFS-SO-FAR 0 :TYPE (INTEGER 0))) + Such code will compile without complaint and work correctly either + on SBCL or on a completely compliant Common Lisp system. 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. 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. @@ -173,39 +173,6 @@ KNOWN BUGS OF NO SPECIAL CLASS: (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. @@ -320,16 +287,6 @@ returning an array as first value always. 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) @@ -348,11 +305,6 @@ returning an array as first value always. 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. @@ -384,6 +336,11 @@ returning an array as first value always. also report on closures, telling about the values of the bound variables. 34: + WHN test case: Compile this file: + (eval-when (:compile-toplevel :load-toplevel :execute) + (defclass a-class () (a))) + (defconstant +a-constant+ (make-instance 'a-class)) + (defconstant +another-constant+ (vector +a-constant+)) as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000: $ cat xx.lisp (defconstant +a-constant+ (make-instance 'a-class)) @@ -444,91 +401,19 @@ returning an array as first value always. 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. + Or perhaps UPGRADED-ARRAY-ELEMENT-TYPE should just fail when a type + isn't defined yet. (What if the definition of + SOMETHING-NOT-DEFINED-YET turns out to be SINGLE-FLOAT?) 41: TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in @@ -780,7 +665,199 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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) + 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)) + => # 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) + 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. + +74: + As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX) + gives a result which isn't COMPLEX. The result type optimizer + for COERCE doesn't know this, perhaps because it was written before + ANSI threw this curveball: the optimizer thinks that COERCE always + returns a result of the specified type. Thus while the interpreted + function + (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX)) + returns the correct result, + (TRICKY 3) => NIL + the compiled function + (COMPILE 'TRICKY) + does not: + (TRICKY 3) => T + +75: + As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, + ANSI says that WITH-OUTPUT-TO-STRING should have a keyword + :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. + +80: + The subtle CMU CL bug discussed by Douglas Thomas Crosher on + cmucl-imp@cons.org 29 Jan 2001 sounds like something that probably + still exists in the corresponding SBCL code. + KNOWN BUGS RELATED TO THE IR1 INTERPRETER @@ -840,3 +917,17 @@ IR1-3a: "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.]