0.7.8.32:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 60c6505..7942a1f 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -184,7 +184,6 @@ WORKAROUND:
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la
     exactly 2.5
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la
     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
@@ -254,23 +253,8 @@ 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.
        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))
-          should signal TYPE-ERROR.
-       i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
-          be used for input and output as needed. It should fail with
-          TYPE-ERROR when handed e.g. the results of
-          MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
-          the inappropriate positions, but doesn't.
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
@@ -280,11 +264,6 @@ WORKAROUND:
        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.
 
-48:
-  SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
-       c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
-          it binds is declared SPECIAL inside.
-
 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
        a: (PROGN
 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
        a: (PROGN
@@ -297,9 +276,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 
@@ -374,26 +350,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)
@@ -461,6 +417,10 @@ WORKAROUND:
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 
+  In fact, the type system is likely to depend on this inequality not
+  holding... * is not equivalent to T in many cases, such as 
+    (VECTOR *) /= (VECTOR T).
+
 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully
 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully
@@ -558,24 +518,6 @@ WORKAROUND:
   time trying to GC afterwards. Surely there's some more economical
   way to implement (ROOM T).
 
   time trying to GC afterwards. Surely there's some more economical
   way to implement (ROOM T).
 
-110:
-  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
-  collection:
-    ;;; The compiler is flushing the argument type test, and the default
-    ;;; case in the cond, so that calling with say a fixnum 0 causes a
-    ;;; SIGBUS.
-    (declaim (optimize (safety 2) (speed 3)))
-    (defun tst (x)
-      (declare (type (or string stream) x))
-      (cond ((typep x 'string) 'string)
-            ((typep x 'stream) 'stream)
-            (t
-             'none)))
-  The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
-  (not the SIGBUS reported in the comment) but that's broken too; 
-  type declarations are supposed to be treated as assertions unless
-  SAFETY 0, so we should be getting a TYPE-ERROR.
-
 115:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:
 115:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:
@@ -665,11 +607,11 @@ WORKAROUND:
 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
-   in the bodies of the macroexpander functions. In particular, it 
-   allows the function bodies (which run at compile time) to try to 
+   in the bodies of the macroexpander functions. In particular, it
+   allows the function bodies (which run at compile time) to try to
    access lexical variables (which are only defined at runtime).
    It doesn't even issue a warning, which is bad.
    access lexical variables (which are only defined at runtime).
    It doesn't even issue a warning, which is bad.
-  
+
    The SBCL behavior arguably conforms to the ANSI spec (since the
    spec says that the behavior is undefined, ergo anything conforms).
    However, it would be better to issue a compile-time error.
    The SBCL behavior arguably conforms to the ANSI spec (since the
    spec says that the behavior is undefined, ergo anything conforms).
    However, it would be better to issue a compile-time error.
@@ -685,7 +627,7 @@ WORKAROUND:
        the local macro definitions in a MACROLET, but the consequences
        are undefined if the local macro definitions reference any
        local variable or function bindings that are visible in that
        the local macro definitions in a MACROLET, but the consequences
        are undefined if the local macro definitions reference any
        local variable or function bindings that are visible in that
-       lexical environment. 
+       lexical environment.
    Then it seems to contradict itself by giving the example
        (defun foo (x flag)
           (macrolet ((fudge (z)
    Then it seems to contradict itself by giving the example
        (defun foo (x flag)
           (macrolet ((fudge (z)
@@ -702,6 +644,12 @@ WORKAROUND:
    but actual specification quoted above says that the actual behavior
    is undefined.
 
    but actual specification quoted above says that the actual behavior
    is undefined.
 
+   (Since 0.7.8.23 macroexpanders are defined in a restricted version
+   of the lexical environment, containing no lexical variables and
+   functions, which seems to conform to ANSI and CLtL2, but signalling
+   a STYLE-WARNING for references to variables similar to locals might
+   be a good thing.)
+
 125:
    (as reported by Gabe Garza on cmucl-help 2001-09-21)
        (defvar *tmp* 3)
 125:
    (as reported by Gabe Garza on cmucl-help 2001-09-21)
        (defvar *tmp* 3)
@@ -726,81 +674,15 @@ WORKAROUND:
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
-129:
-  insufficient syntax checking in MACROLET:
-   (defun foo (x)
-     (macrolet ((defmacro bar (z) `(+ z z)))
-       (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
 135:
   Ideally, uninterning a symbol would allow it, and its associated
-  FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
+  FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
   at least as of sbcl-0.7.0, this isn't the case. Information about
   FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
   essentially in ordinary (non-weak) hash tables keyed by symbols.
   Thus, once a system has an entry in this system, it tends to live
   forever, even when it is uninterned and all other references to it
   at least as of sbcl-0.7.0, this isn't the case. Information about
   FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
   essentially in ordinary (non-weak) hash tables keyed by symbols.
   Thus, once a system has an entry in this system, it tends to live
   forever, even when it is uninterned and all other references to it
-  are lost. 
+  are lost.
 
 136:
   (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
 
 136:
   (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
@@ -830,7 +712,7 @@ WORKAROUND:
   T
   * (defclass b () ())
   #<STANDARD-CLASS B>
   T
   * (defclass b () ())
   #<STANDARD-CLASS B>
-   
+
   ;;; And now...
   * (subtypep 'b 'a)
   T
   ;;; And now...
   * (subtypep 'b 'a)
   T
@@ -838,7 +720,7 @@ WORKAROUND:
 
   This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
   class upon redefinition. Unfortunately, doing so causes bug #176 to
 
   This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
   class upon redefinition. Unfortunately, doing so causes bug #176 to
-  appear.  Pending further investication, one or other of these bugs
+  appear.  Pending further investigation, one or other of these bugs
   might be present at any given time.
 
 141: 
   might be present at any given time.
 
 141: 
@@ -849,12 +731,6 @@ WORKAROUND:
   * (lisp-implementation-version)
   "0.pre7.129"
 
   * (lisp-implementation-version)
   "0.pre7.129"
 
-142:
-  (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
-  %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
-  of the naturalized string. We could probably port the patches
-  from the cmucl-imp mailing list.
-
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
   prominent SourceForge web/db bug tracking system, which is 
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
   prominent SourceForge web/db bug tracking system, which is 
@@ -936,27 +812,14 @@ WORKAROUND:
     debugger invoked on condition of type TYPE-ERROR:
       The value NIL is not of type SB-C::NODE.
   The location of this failure has moved around as various related
     debugger invoked on condition of type TYPE-ERROR:
       The value NIL is not of type SB-C::NODE.
   The location of this failure has moved around as various related
-  issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
+  issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
 
   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
 
-153:
-  (essentially the same problem as a CMU CL bug reported by Martin
-  Cracauer on cmucl-imp 2002-02-19)
-  There is a hole in structure slot type checking. Compiling and LOADing
-    (declaim (optimize safety))
-    (defstruct foo
-      (bla 0 :type fixnum))
-    (defun f ()
-      (let ((foo (make-foo)))
-        (setf (foo-bla foo) '(1 . 1))
-        (format t "Is ~a of type ~a a cons? => ~a~%"
-                (foo-bla foo)
-                (type-of (foo-bla foo))
-                (consp (foo-bla foo)))))
-    (f)
-  should signal an error, but in sbcl-0.7.1.21 instead gives the output
-    Is (1 . 1) of type CONS a cons? => NIL
-  without signalling an error.
+  (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
+  expand KID-FROB into %ZEEP. Having partially done it, it sees a call
+  of KIDIFY1, which already does not exist. So it gives up on
+  expansion, leaving garbage consisting of infinished blocks of the
+  partially converted function.)
 
 157:
   Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
 
 157:
   Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
@@ -1022,18 +885,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. 
-
 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:
@@ -1094,24 +945,14 @@ WORKAROUND:
   In sbcl-0.7.4.24, compiling
     (defun bug178 (x)
       (funcall (the function (the standard-object x))))
   In sbcl-0.7.4.24, compiling
     (defun bug178 (x)
       (funcall (the function (the standard-object x))))
-  gives 
+  gives
     failed AVER:
       "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
   This variant compiles OK, though:
     (defun bug178alternative (x)
       (funcall (the nil x)))
 
     failed AVER:
       "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
   This variant compiles OK, though:
     (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.
+  (since 0.7.8.9 it does not signal an error; see also bug 199)
 
 183: "IEEE floating point issues"
   Even where floating point handling is being dealt with relatively
 
 183: "IEEE floating point issues"
   Even where floating point handling is being dealt with relatively
@@ -1281,6 +1122,8 @@ WORKAROUND:
              (print j))))
        (trust-assertion 6) ; prints nothing unless DECLARE is commented out
 
              (print j))))
        (trust-assertion 6) ; prints nothing unless DECLARE is commented out
 
+     (see bug 203)
+
 193: "unhelpful CLOS error reporting when the primary method is missing"
   In sbcl-0.7.7, when
     (defmethod foo :before ((x t)) (print x))
 193: "unhelpful CLOS error reporting when the primary method is missing"
   In sbcl-0.7.7, when
     (defmethod foo :before ((x t)) (print x))
@@ -1341,17 +1184,93 @@ WORKAROUND:
       works as it should. Perhaps this is another case of VALUES type
       intersections behaving in non-useful ways?
 
       works as it should. Perhaps this is another case of VALUES type
       intersections behaving in non-useful ways?
 
-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)
+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.
+
+  (this case was fixed in 0.7.8.9; see also bug 178)
+
+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"
+
+203:
+  Compiler does not check THEs on unused values, e.g. in
+
+    (progn (the real (list 1)) t)
+
+  This situation may appear during optimizing away degenerate cases of
+  certain functions: see bugs 54, 192b.
+
+205: "environment issues in cross compiler"
+  (These bugs have no impact on user code, but should be fixed or
+  documented.)
+  a. Macroexpanders introduced with MACROLET are defined in the null
+     lexical environment.
+  b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
+     the null lexical environment.
+
+206: ":SB-FLUID feature broken"
+  (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
+  Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
+  the build.
+
+207: "poorly distributed SXHASH results for compound data"
+  SBCL's SXHASH could probably try a little harder. ANSI: "the
+  intent is that an implementation should make a good-faith
+  effort to produce hash-codes that are well distributed
+  within the range of non-negative fixnums". But
+       (let ((hits (make-hash-table)))
+         (dotimes (i 16)
+           (dotimes (j 16)
+             (let* ((ij (cons i j))
+                     (newlist (push ij (gethash (sxhash ij) hits))))
+               (when (cdr newlist)
+                 (format t "~&collision: ~S~%" newlist))))))
+  reports lots of collisions in sbcl-0.7.8. A stronger MIX function
+  would be an obvious way of fix. Maybe it would be acceptably efficient
+  to redo MIX using a lookup into a 256-entry s-box containing
+  29-bit pseudorandom numbers?
+
+208: "package confusion in PCL handling of structure slot handlers"
+  In sbcl-0.7.8 compiling and loading 
+       (in-package :cl)
+       (defstruct foo (slot (error "missing")) :type list :read-only t)
+       (defmethod print-object ((foo foo) stream) (print nil stream))
+  causes CERROR "attempting to modify a symbol in the COMMON-LISP
+  package: FOO-SLOT". (This is fairly bad code, but still it's hard
+  to see that it should cause symbols to be interned in the CL package.)
+
+209: "DOCUMENTATION generic function has wrong argument precedence order"
+  The method from 
+    (DEFMETHOD DOCUMENTATION ((X (EQL '+)) Y) "WRONG!")
+  should not be executed in the call 
+    (DOCUMENTATION '+ 'FUNCTION),
+  as the DOCUMENTATION generic function has a different argument
+  precedence order (see its entry in the CLHS). However, despite a
+  correct generic function definition in the PCL source code, SBCL
+  returns "WRONG!" for the call.
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: