0.6.11.40:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index a2c61e5..ad30c7b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -225,10 +225,12 @@ WORKAROUND:
 
 26:
   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
-
-Also, there is another bug: `array-displacement' should return an array
-or nil as first value (as per ANSI CL), while CMUCL declares it as
-returning an array as first value always.
+    Also, there is another bug: `array-displacement' should return an
+    array or nil as first value (as per ANSI CL), while CMUCL declares
+    it as returning an array as first value always.
+  (Actually, I think the old CMU CL version in SBCL never returns NIL,
+  i.e. it's not just a declaration problem, but the definition doesn't
+  behave ANSIly.)
 
 27:
   Sometimes (SB-EXT:QUIT) fails with 
@@ -811,13 +813,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 
-87:
-  Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause
-  things to be byte compiled. This seems to be true in cmucl-2.4.19,
-  too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation,
-  but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0))
-  does not.
-
 90: 
   a latent cross-compilation/bootstrapping bug: The cross-compilation
   host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
@@ -838,13 +833,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   clear what's the best fix. (See the "bug in type handling" discussion
   on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
 
-92:
-  (< SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY 100) signals an error:
-    error in function SB-KERNEL:INTEGER-DECODE-SINGLE-FLOAT:
-      can't decode NaN or infinity: #.EXT:SINGLE-FLOAT-POSITIVE-INFINITY
-  This is a bug in the original CMU CL code. I reported it to cmucl-imp
-  2001-03-22 in hopes that they'll fix it for us.
-
 93:
   In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
   src/cold/shared.lisp doesn't correctly translate the
@@ -864,6 +852,57 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
       (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
        :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
 
+94a: 
+  Inconsistencies between derived and declared VALUES return types for
+  DEFUN aren't checked very well. E.g. the logic which successfully
+  catches problems like
+    (declaim (ftype (function (fixnum) float) foo))
+    (defun foo (x)
+      (declare (type integer x))
+      (values x)) ; wrong return type, detected, gives warning, good!
+  fails to catch
+    (declaim (ftype (function (t) (values t t)) bar))
+    (defun bar (x)
+      (values x)) ; wrong number of return values, no warning, bad!
+  The cause of this is seems to be that (1) the internal function 
+  VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
+  arguments symmetrically, and (2) when the type checking code was
+  written back when when SBCL's code was still CMU CL, the intent
+  was that this case
+    (declaim (ftype (function (t) t) bar))
+    (defun bar (x)
+      (values x x)) ; wrong number of return values; should give warning?
+  not be warned for, because a two-valued return value is considered
+  to be compatible with callers who expects a single value to be
+  returned. That intent is probably not appropriate for modern ANSI
+  Common Lisp, but fixing this might be complicated because of other
+  divergences between auld-style and new-style handling of
+  multiple-VALUES types. (Some issues related to this were discussed
+  on cmucl-imp at some length sometime in 2000.)
+
+95:
+  The facility for dumping a running Lisp image to disk gets confused
+  when run without the PURIFY option, and creates an unnecessarily large
+  core file (apparently representing memory usage up to the previous
+  high-water mark). Moreover, when the file is loaded, it confuses the
+  GC, so that thereafter memory usage can never be reduced below that
+  level.
+
+96:
+  The TRACE facility can't be used on some kinds of functions.
+  Basically, the breakpoint facility wasn incompletely implemented
+  in the X86 port of CMU CL, and we haven't fixed it in SBCL.
+
+97:
+  FRESH-LINE doesn't seem to work properly within pretty-printed
+  output. E.g. 
+    "~@<unhandled CONDITION (of type ~S): ~2I~_~A~:>~2%"
+  called on a CONDITION whose printer does
+    "~&~@<error in function ~S: ~3I~:_~?~:>"
+  gives two newlines between "unhandled CONDITION" and "error", when
+  (it at least seems as though) correct behavior would be to give one.
+
+
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Note: At some point, the pure interpreter (actually a semi-pure