0.6.10.13:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 9cba6dc..68cbee7 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -173,10 +173,6 @@ WORKAROUND:
   (Also, when this is fixed, we can enable the code in PROCLAIM which 
   checks for incompatible FTYPE redeclarations.)
 
   (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.
-

 18:
   from DTC on the CMU CL mailing list 25 Feb 2000:
 ;;; Compiler fails when this file is compiled.
 18:
   from DTC on the CMU CL mailing list 25 Feb 2000:
 ;;; Compiler fails when this file is compiled.

@@ -309,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.
 
    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.
 31:
   In some cases the compiler believes type declarations on array
   elements without checking them, e.g.

@@ -345,6 +336,11 @@ returning an array as first value always.
   also report on closures, telling about the values of the bound variables.
 
 34:
   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))
   as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000:
     $ cat xx.lisp
     (defconstant +a-constant+ (make-instance 'a-class))

@@ -405,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.)
 
   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)
 
 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.
 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 
 
 41:
   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 

@@ -762,6 +686,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   rightward of the correct location.
 
 65:
   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")
   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
   compiling this file
 (in-package "CL-USER")

@@ -858,6 +783,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   or at least issue a warning.
 
 70:
   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))
   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
   forms. E.g.
     (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))

@@ -884,7 +810,53 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   0.6.9.x in a general cleanup of optimization policy.
 
 72:
   0.6.9.x in a general cleanup of optimization policy.
 
 72:

-  (DECLAIM (OPTIMIZE ..)) doesn't work inside LOCALLY.
+  (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
 
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER