0.7.7.38:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 12a9426..ea797df 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,4 +1,4 @@
-tREPORTING BUGS
+REPORTING BUGS
 
 Bugs can be reported on the help mailing list
   sbcl-help@lists.sourceforge.net
 
 Bugs can be reported on the help mailing list
   sbcl-help@lists.sourceforge.net
@@ -183,7 +183,8 @@ WORKAROUND:
   then executing
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la
   then executing
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la
-    exactly 1.33..
+    exactly 2.5
+  (or (FOO 1000.5), "exactly 1001.5")
   This violates the "declarations are assertions" principle.
   According to the ANSI spec, in the section "System Class FUNCTION",
   this is a case of "lying to the compiler", but the lying is done
   This violates the "declarations are assertions" principle.
   According to the ANSI spec, in the section "System Class FUNCTION",
   this is a case of "lying to the compiler", but the lying is done
@@ -253,14 +254,6 @@ WORKAROUND:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:
 
 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))
        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))
@@ -276,13 +269,6 @@ WORKAROUND:
 
 47:
   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
 
 47:
   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
-       a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
-          doesn't.
-       b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
-          signal a PROGRAM-ERROR, and doesn't.
-       c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
-          and other DEFCLASS forms with duplicate specifications in their
-          slots, should signal a PROGRAM-ERROR, and doesn't.
        d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
           causes a COMPILER-ERROR.
 
        d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
           causes a COMPILER-ERROR.
 
@@ -303,9 +289,6 @@ WORKAROUND:
              (DEFGENERIC FOO03 (X))
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.
              (DEFGENERIC FOO03 (X))
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.
-       b: READ should probably return READER-ERROR, not the bare 
-          arithmetic error, when input a la "1/0" or "1e1000" causes
-          an arithmetic error.
 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 
 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 
@@ -380,26 +363,6 @@ WORKAROUND:
   the new output block should start indented 2 or more characters
   rightward of the correct location.
 
   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)
 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)
@@ -739,65 +702,6 @@ WORKAROUND:
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 
-131:
-  As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
-  the CL:COMPILE function (which is based on the same %COMPILE 
-  mechanism) get confused by 
-(defun sxhash (x)
-  (labels ((sxhash-number (x)
-            (etypecase x
-              (fixnum (sxhash x)) ; through DEFTRANSFORM
-              (integer (sb!bignum:sxhash-bignum x))
-              (single-float (sxhash x)) ; through DEFTRANSFORM
-              (double-float (sxhash x)) ; through DEFTRANSFORM
-              #!+long-float (long-float (error "stub: no LONG-FLOAT"))
-              (ratio (let ((result 127810327))
-                       (declare (type fixnum result))
-                       (mixf result (sxhash-number (numerator x)))
-                       (mixf result (sxhash-number (denominator x)))
-                       result))
-              (complex (let ((result 535698211))
-                         (declare (type fixnum result))
-                         (mixf result (sxhash-number (realpart x)))
-                         (mixf result (sxhash-number (imagpart x)))
-                         result))))
-          (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
-            (declare (type index depthoid))
-            (typecase x
-              (list
-               (if (plusp depthoid)
-                   (mix (sxhash-recurse (car x) (1- depthoid))
-                        (sxhash-recurse (cdr x) (1- depthoid)))
-                   261835505))
-              (instance
-               (if (typep x 'structure-object)
-                   (logxor 422371266
-                           (sxhash ; through DEFTRANSFORM
-                            (class-name (layout-class (%instance-layout x)))))
-                   309518995))
-              (symbol (sxhash x)) ; through DEFTRANSFORM
-              (number (sxhash-number x))
-              (array
-               (typecase x
-                 (simple-string (sxhash x)) ; through DEFTRANSFORM
-                 (string (%sxhash-substring x))
-                 (bit-vector (let ((result 410823708))
-                               (declare (type fixnum result))
-                               (dotimes (i (min depthoid (length x)))
-                                 (mixf result (aref x i)))
-                               result))
-                 (t (logxor 191020317 (sxhash (array-rank x))))))
-              (character
-               (logxor 72185131
-                       (sxhash (char-code x)))) ; through DEFTRANSFORM
-              (t 42))))
-    (sxhash-recurse x)))
-  complaining "function called with two arguments, but wants exactly
-  one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
-  since IIRC post-fork CMU CL has also had problems with &OPTIONAL
-  arguments in FLET/LABELS: it might be an old Python bug which is 
-  only exercised by the new arrangement of the SBCL compiler.)
-
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
@@ -1028,23 +932,6 @@ WORKAROUND:
   macro is unhappy with the illegal syntax in the method body, and
   is giving an unclear error message.
 
   macro is unhappy with the illegal syntax in the method body, and
   is giving an unclear error message.
 
-168:
-  (reported by Dan Barlow on sbcl-devel 2002-05-10)
-  In sbcl-0.7.3.12, doing
-    (defstruct foo bar baz)
-    (compile nil (lambda (x) (or x (foo-baz x))))
-  gives an error
-    debugger invoked on condition of type SB-INT:BUG:
-       full call to SB-KERNEL:%INSTANCE-REF
-    This is probably a bug in SBCL itself. [...]
-  Since this is a reasonable user error, it shouldn't be reported as 
-  an SBCL bug. 
-
-171:
-  (reported by Pierre Mai while investigating bug 47):
-    (DEFCLASS FOO () ((A :SILLY T))) 
-  signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
-
 172:
   sbcl's treatment of at least macro lambda lists is too permissive;
   e.g., in sbcl-0.7.3.7:
 172:
   sbcl's treatment of at least macro lambda lists is too permissive;
   e.g., in sbcl-0.7.3.7:
@@ -1112,18 +999,6 @@ WORKAROUND:
     (defun bug178alternative (x)
       (funcall (the nil x)))
 
     (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
 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
@@ -1280,17 +1155,9 @@ WORKAROUND:
      lists and &KEY arguments) do not signal errors when they should.
 
 192: "Python treats free type declarations as promises."
      lists and &KEY arguments) do not signal errors when they should.
 
 192: "Python treats free type declarations as promises."
-  a. original report by Alexey Dejneka (on sbcl-devel 2002-08-26):
-       (declaim (optimize (speed 0) (safety 3)))
-       (defun f (x)
-         (declare (real x))
-         (+ x
-            (locally (declare (single-float x))
-            (sin x))))
-     Now (F NIL) correctly gives a type error, but (F 100) gives
-     a segmentation violation.
-  b. same fundamental problem in a different way, easy to stumble
-     across if you mistype and declare the wrong index in
+  b. What seemed like the same fundamental problem as bug 192a, but
+     was not fixed by the same (APD "more strict type checking
+     sbcl-devel 2002-08-97) patch:
      (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
        (declaim (optimize (speed 1) (safety 3)))
        (defun trust-assertion (i)
      (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
        (declaim (optimize (speed 1) (safety 3)))
        (defun trust-assertion (i)
@@ -1320,8 +1187,31 @@ WORKAROUND:
   bad argument value is).
 
 194: "no error from (THE REAL '(1 2 3)) in some cases"
   bad argument value is).
 
 194: "no error from (THE REAL '(1 2 3)) in some cases"
-  (Actually this entry is probably two separate bugs, as
-  Alexey Dejneka commented on sbcl-devel 2002-09-03:)
+  fixed parts:
+    a. In sbcl-0.7.7.9, 
+         (multiple-value-prog1 (progn (the real '(1 2 3))))
+       returns (1 2 3) instead of signalling an error. This was fixed by 
+       APD's "more strict type checking patch", but although the fixed
+       code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
+       it's difficult to write a regression test for it, because 
+       (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
+       still returns (1 2 3).
+  still-broken parts:  
+    b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))    
+       returns (1 2 3). (As above, this shows up when writing regression
+       tests for fixed-ness of part a.)
+    c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
+    d. At the REPL,
+         (null (ignore-errors
+           (let ((arg1 1)
+                 (arg2 (identity (the real #(1 2 3)))))
+             (if (< arg1 arg2) arg1 arg2))))
+           => T
+      but putting the same expression inside (DEFUN FOO () ...),
+      (FOO) => NIL.
+  notes:
+    * Actually this entry is probably multiple bugs, as
+      Alexey Dejneka commented on sbcl-devel 2002-09-03:)
        I don't think that placing these two bugs in one entry is
        a good idea: they have different explanations. The second
        (min 1 nil) is caused by flushing of unused code--IDENTITY
        I don't think that placing these two bugs in one entry is
        a good idea: they have different explanations. The second
        (min 1 nil) is caused by flushing of unused code--IDENTITY
@@ -1330,47 +1220,41 @@ WORKAROUND:
        for the result, it forgets about type assertion. The purpose
        of IDENTITY is to save the restricted continuation from
        inaccurate transformations.
        for the result, it forgets about type assertion. The purpose
        of IDENTITY is to save the restricted continuation from
        inaccurate transformations.
-  In sbcl-0.7.7.9, 
-    (multiple-value-prog1 (progn (the real '(1 2 3))))
-  returns (1 2 3) instead of signalling an error. Also in sbcl-0.7.7.9,
-  a more complicated instance of this bug kept 
-  (IGNORE-ERRORS (MIN '(1 2 3))) from returning NIL as it should when
-  the MIN source transform expanded to (THE REAL '(1 2 3)), because
-  (IGNORE-ERRORS (THE REAL '(1 2 3))) returns (1 2 3).
-  Alexey Dejneka pointed out that
-  (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) works as it should.
-  (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) also works as it should.
-  Perhaps this is another case of VALUES type intersections behaving
-  in non-useful ways?
-    When I (WHN) tried to use the VALUES trick to work around this bug
-  in the MIN source transform, it didn't work for
-    (assert (null (ignore-errors (min 1 #(1 2 3)))))
-  Hand-expanding the source transform, I get
-    (assert (null (ignore-errors
-                   (let ((arg1 1)
-                         (arg2 (identity (the real #(1 2 3)))))
-                     (if (< arg1 arg2) arg1 arg2))))) 
-  which fails (i.e. the assertion fails, because the IGNORE-ERRORS
-  doesn't report MIN signalling a type error). At the REPL
-    (null (ignore-errors
-           (let ((arg1 1)
-                 (arg2 (identity (the real #(1 2 3)))))
-             (if (< arg1 arg2) arg1 arg2))))
-    => T
-  but when this expression is used as the body of (DEFUN FOO () ...)
-  then (FOO)=>NIL.
-
-195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL"
-  In sbcl-0.7.7.10, (THE REAL #(1 2 3)) signals a type error which
-  prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)".
-  The (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL) representation of
-  REAL is unnecessarily confusing, especially since it relies on 
-  internal implementation knowledge that even with SHORT-FLOAT
-  and LONG-FLOAT left out of the union, this type is equal to REAL.
-  So it'd be better just to say "This is not a REAL".
-
-196: "confusing error message for unREAL second arg to ATAN"
-  (fixed in sbcl-0.7.7.18)
+    * Alexey Dejneka pointed out that
+       (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
+      works as it should. Also
+       (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
+      works as it should. Perhaps this is another case of VALUES type
+      intersections behaving in non-useful ways?
+
+199: "hairy FUNCTION types confuse the compiler"
+  (reported by APD sbcl-devel 2002-09-15)
+    (DEFUN MUR (F)
+      (EQ NIL (FUNCALL F)))
+
+    (DEFUN FOO (F X)
+      (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F))
+      (FUNCALL F X))
+
+  fails to compile, printing
+    failed AVER:
+      "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+
+  APD further reports that this bug is not present in CMUCL.
+
+201: "Incautious type inference from compound CONS types"
+  (reported by APD sbcl-devel 2002-09-17)
+    (DEFUN FOO (X)
+      (LET ((Y (CAR (THE (CONS INTEGER *) X))))
+        (SETF (CAR X) NIL)
+        (FORMAT NIL "~S IS ~S, Y = ~S"
+                (CAR X)
+                (TYPECASE (CAR X)
+                  (INTEGER 'INTEGER)
+                  (T '(NOT INTEGER)))
+                Y)))
+
+    (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: