X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=68cbee7b93df6dc0b501da71d5db4f41c0c63e83;hb=4fc9d21ae1d8a6a2f8ff70f589d5da103203de13;hp=a277e017f97eefe312f4a1f7b3cc8d9212ea0f85;hpb=8c66abea806a03de36af37eb6068718799617b92;p=sbcl.git diff --git a/BUGS b/BUGS index a277e01..68cbee7 100644 --- a/BUGS +++ b/BUGS @@ -43,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. @@ -174,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. @@ -339,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. @@ -375,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)) @@ -435,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 @@ -792,6 +686,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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") @@ -861,6 +756,108 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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