0.8.5.29:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 688b166..fed7fc3 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -184,15 +184,6 @@ WORKAROUND:
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.
 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.
 

-46:
-  type safety errors reported by Peter Van Eynde July 25, 2000:
-       k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
-          not a binary input stream, but instead cheerfully reads from
-          string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
-  [ Bug was reported as "from character streams", but in 0.8.3.10 we
-  get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ]
-
-

 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
   (How should it work properly?)
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
   (How should it work properly?)

@@ -377,14 +368,6 @@ WORKAROUND:
    Raymond Toy comments that this is tricky on the X86 since its FPU
    uses 80-bit precision internally.
 
    Raymond Toy comments that this is tricky on the X86 since its FPU
    uses 80-bit precision internally.
 

-120b:
-   Even in sbcl-0.pre7.x, which is supposed to be free of the old
-   non-ANSI behavior of treating the function return type inferred
-   from the current function definition as a declaration of the
-   return type from any function of that name, the return type of NIL
-   is attached to FOO in 120a above, and used to optimize code which
-   calls FOO. 
-

 124:
    As of version 0.pre7.14, SBCL's implementation of MACROLET makes
    the entire lexical environment at the point of MACROLET available
 124:
    As of version 0.pre7.14, SBCL's implementation of MACROLET makes
    the entire lexical environment at the point of MACROLET available

@@ -464,11 +447,7 @@ WORKAROUND:
     * '``(FOO ,@',@S)
     ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
 
     * '``(FOO ,@',@S)
     ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
 

-  b.
-    * (write '`(, .ala.) :readably t :pretty t)
-    `(,.ALA.)
-
-  (note the space between the comma and the point)
+  b. (fixed in 0.8.4.7)

 
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
 
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately

@@ -646,8 +625,7 @@ WORKAROUND:
      classes).  This means that at present erroneous attempts to use
      WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
      won't get the corresponding STYLE-WARNING.
      classes).  This means that at present erroneous attempts to use
      WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
      won't get the corresponding STYLE-WARNING.

-  c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
-     lists and &KEY arguments) do not signal errors when they should.
+  c. (fixed in 0.8.4.23)

 
 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
 
 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)

@@ -734,11 +712,7 @@ WORKAROUND:
   all of the arguments are circular is probably desireable).
 
 213: "Sequence functions and type checking"
   all of the arguments are circular is probably desireable).
 
 213: "Sequence functions and type checking"

-  a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
-     various complicated, though recognizeable, CONS types [e.g.
-       (CONS * (CONS * NULL))
-     which according to ANSI should be recognized] (and, in SAFETY 3
-     code, should return a list of LENGTH 2 or signal an error)
+  a. (fixed in 0.8.4.36)

   b. MAP, when given a type argument that is SUBTYPEP LIST, does not
      check that it will return a sequence of the given type.  Fixing
      it along the same lines as the others (cf. work done around
   b. MAP, when given a type argument that is SUBTYPEP LIST, does not
      check that it will return a sequence of the given type.  Fixing
      it along the same lines as the others (cf. work done around

@@ -901,10 +875,6 @@ WORKAROUND:
   a. On X86 an immediate operand for IMUL is printed incorrectly.
   b. On X86 operand size prefix is not recognized.
 
   a. On X86 an immediate operand for IMUL is printed incorrectly.
   b. On X86 operand size prefix is not recognized.
 

-248: "reporting errors in type specifier syntax"
-  (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
-  specifier".
-

 251:
   (defun foo (&key (a :x))
     (declare (fixnum a))
 251:
   (defun foo (&key (a :x))
     (declare (fixnum a))

@@ -967,11 +937,6 @@ WORKAROUND:
 
   b. The same for CSUBTYPEP.
 
 
   b. The same for CSUBTYPEP.
 

-261:
-    * (let () (list (the (values &optional fixnum) (eval '(values)))))
-    debugger invoked on condition of type TYPE-ERROR:
-      The value NIL is not of type FIXNUM.
-

 262: "yet another bug in inline expansion of local functions"
   Compiler fails on
 
 262: "yet another bug in inline expansion of local functions"
   Compiler fails on
 

@@ -994,12 +959,6 @@ WORKAROUND:
 
   Urgh... It's time to write IR1-copier.
 
 
   Urgh... It's time to write IR1-copier.
 

-265:
-  SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
-  attempting to use it leads to segmentation violations.  This is
-  probably because of a bogus implementation of
-  os_restore_fp_control().
-

 266:
   David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
   behaviour of streams with element-type (SIGNED-BYTE 8).  The patch
 266:
   David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
   behaviour of streams with element-type (SIGNED-BYTE 8).  The patch

@@ -1188,20 +1147,12 @@ WORKAROUND:
   this problem.
 
 288: fundamental cross-compilation issues (from old UGLINESS file)
   this problem.
 
 288: fundamental cross-compilation issues (from old UGLINESS file)

-  288a: Using host floating point numbers to represent target
-    floating point numbers, or host characters to represent
-    target characters, is theoretically shaky. (The characters
-    are OK as long as the characters are in the ANSI-guaranteed
-    character set, though, so they aren't a real problem as
-    long as the sources don't need anything but that.)
-  288b: The compiler still makes assumptions about cross-compilation-host
-    implementation of ANSI CL:
-    288b1: Simple bit vectors are distinct from simple vectors (in
-       DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure*
-       that things would really break if this weren't so, but I 
-       strongly suspect that they would.)
-    288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is 
-       in a sense just one aspect of bug 288a.)
+  Using host floating point numbers to represent target floating point
+  numbers, or host characters to represent target characters, is
+  theoretically shaky. (The characters are OK as long as the characters
+  are in the ANSI-guaranteed character set, though, so they aren't a
+  real problem as long as the sources don't need anything but that;
+  the floats are a real problem.)

 
 289: "type checking and source-transforms"
   a.
 
 289: "type checking and source-transforms"
   a.

@@ -1232,11 +1183,6 @@ WORKAROUND:
   the control word; however, this clobbers any change the user might
   have made.
 
   the control word; however, this clobbers any change the user might
   have made.
 

-295:
-  From Paul Dietz:
-
-  (ash -1000000000000 -10000000000000000000) ==> 0  ;; should be -1
-

 296:
   (reported by Adam Warner, sbcl-devel 2003-09-23)
 
 296:
   (reported by Adam Warner, sbcl-devel 2003-09-23)
 

@@ -1244,3 +1190,12 @@ WORKAROUND:
   argument.  As a result, files with Lisp pathname pattern characters
   (#\* or #\?, for instance) or quotation marks can cause the system
   to perform arbitrary behaviour.
   argument.  As a result, files with Lisp pathname pattern characters
   (#\* or #\?, for instance) or quotation marks can cause the system
   to perform arbitrary behaviour.

+
+297:
+  LOOP with non-constant arithmetic step clauses suffers from overzealous
+  type constraint: code of the form 
+    (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
+  compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
+  (0))).  However, an integral value of X should be legal, because
+  successive adds of integers to double-floats produces double-floats,
+  so none of the type restrictions in the code is violated.