0.6.10.13:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 39c0299..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.)
 
-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.
@@ -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.
 
-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.
@@ -345,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))
@@ -405,36 +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.
-
 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 
@@ -833,17 +812,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 72:
   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
 
-73:
-  PROCLAIM and DECLAIM don't recognize the ANSI abbreviated type
-  declaration syntax for user-defined types, although DECLARE does.
-  E.g.
-       (deftype foo () '(integer 3 19))
-       (defvar *foo*)
-       (declaim (foo *foo*)) ; generates warning
-       (defun foo+ (x y)
-         (declare (foo x y)) ; works OK
-         (+ x y))
-
 74:
   As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
   gives a result which isn't COMPLEX. The result type optimizer
@@ -865,6 +833,31 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   :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