0.7.8.47:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index c0b8f47..4f7bea2 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -264,11 +264,6 @@ WORKAROUND:
        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
@@ -649,6 +644,12 @@ WORKAROUND:
    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)
@@ -1222,19 +1223,89 @@ WORKAROUND:
   This situation may appear during optimizing away degenerate cases of
   certain functions: see bugs 54, 192b.
 
-204:
-  (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) inside MACROLET evaluates its
-  argument in the null lexical environment. E.g. compiling file with
-
-    (macrolet ((def (x) `(print ,x)))
-      (eval-when (:compile-toplevel)
-        (def 'hello)))
-
-  causes
-
-    debugger invoked on condition of type UNDEFINED-FUNCTION:
-      The function DEF is undefined.
-
+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"
+  (fixed in sbcl-0.7.8.39)
+
+210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors"
+  (fixed in sbcl-0.7.8.35)
+
+211: "keywords processing"
+  a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
+     number of keyword arguments.
+  b. Compiling of a local call with an unknown key and
+     :ALLOW-OTHER-KEYS T should not cause a WARNING.
+  c. Compiler should not warn on an unknown key :ALLOW-OTHER-KEYS.
+  d. :ALLOW-OTHER-KEYS should be allowed as an ordinary key parameter.
+
+212: "Sequence functions and circular arguments"
+  COERCE, MERGE and CONCATENATE go into an infinite loop when given
+  circular arguments; it would be good for the user if they could be
+  given an error instead (ANSI 17.1.1 allows this behaviour on the part
+  of the implementation, as conforming code cannot give non-proper
+  sequences to these functions.  MAP also has this problem (and
+  solution), though arguably the convenience of being able to do 
+    (MAP 'LIST '+ FOO '#1=(1 . #1#)) 
+  might be classed as more important (though signalling an error when
+  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)
+  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
+     sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
+     entirely straightforward.
+  c. All of these functions will silently accept a type of the form
+       (CONS INTEGER *)
+     whether or not the return value is of this type.  This is
+     probably permitted by ANSI (see "Exceptional Situations" under
+     ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not 
+     know about this escape clause, so code of the form
+       (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
+     can erroneously return T.
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: