0.7.8.1:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 25d6de4..b7c3b53 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -254,6 +254,14 @@ WORKAROUND:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:
+       a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
+          => #(A B C)
+          In general lengths of array type specifications aren't
+          checked by COERCE, so it fails when the spec is
+          (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
+       b: CONCATENATE has the same problem of not checking the length
+          of specified output array types. MAKE-SEQUENCE and MAP and
+          MERGE also have the same problem.
        c: (COERCE 'AND 'FUNCTION) returns something related to
           (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
        h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
@@ -363,6 +371,26 @@ WORKAROUND:
   the new output block should start indented 2 or more characters
   rightward of the correct location.
 
+66:
+  ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
+  a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
+    (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
+  This also leads to funny behavior when derived type specifiers
+  are used, as originally reported by Milan Zamazal for CMU CL (on the
+  Debian bugs mailing list (?) 2000-02-27), then reported by Martin
+  Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
+    (DEFTYPE FOO () 'SIMPLE-ARRAY)
+    (CONCATENATE 'FOO #(1 2) '(3)) 
+      => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
+           sequence functions.
+  The derived type specifier FOO should act the same way as the 
+  built-in type SIMPLE-ARRAY here, but it doesn't. That problem
+  doesn't seem to exist for sequence types:
+    (DEFTYPE BAR () 'SIMPLE-VECTOR)
+    (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
+  See also bug #46a./b., and discussion and patch sbcl-devel and
+  cmucl-imp 2002-07
+
 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)
@@ -999,18 +1027,6 @@ WORKAROUND:
     (defun bug178alternative (x)
       (funcall (the nil x)))
 
-181: "bad type specifier drops compiler into debugger"
-  Compiling 
-    (in-package :cl-user)
-    (defun bar (x)
-      (declare (type 0 x))
-      (cons x x))
-  signals 
-    bad thing to be a type specifier: 0
-  which seems fine, but also enters the debugger (instead of having
-  the compiler handle the error, convert it into a COMPILER-ERROR, and
-  continue compiling) which seems wrong.
-
 183: "IEEE floating point issues"
   Even where floating point handling is being dealt with relatively
   well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
@@ -1268,6 +1284,28 @@ WORKAROUND:
 
     (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
 
+202:
+  In 0.6.12.43 compilation of a function definition, contradicting its
+  FTYPE proclamation, causes an error, e.g. COMPILE-FILE on
+
+    (declaim (ftype (function () null) foo))
+    (defun foo () t)
+
+  fails with
+
+    debugger invoked on condition of type UNBOUND-VARIABLE:
+    The variable SB-C::*ERROR-FUNCTION* is unbound.
+
+  in
+
+    (SB-C::NOTE-LOSSAGE
+       "~@<The previously declared FTYPE~2I ~_~S~I ~_~
+                              conflicts with the definition type ~2I~_~S~:>"
+       (FUNCTION NIL NULL)
+       (FUNCTION NIL #))
+
+  (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.)
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.