0.9.4.68:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 42b6a8e..a9bd148 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1074,13 +1074,6 @@ WORKAROUND:
   around the same time regarding a call to LIST on sparc with 1000
   arguments) and other implementation limit constants.
 
   around the same time regarding a call to LIST on sparc with 1000
   arguments) and other implementation limit constants.
 
-311: "Tokeniser not thread-safe"
-    (see also Robert Marlow sbcl-help "Multi threaded read chucking a
-    spak" 2004-04-19)
-  The tokenizer's use of *read-buffer* and *read-buffer-length* causes
-  spurious errors should two threads attempt to tokenise at the same
-  time.
-
 314: "LOOP :INITIALLY clauses and scope of initializers"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite, originally by Thomas F. Burdick.
 314: "LOOP :INITIALLY clauses and scope of initializers"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite, originally by Thomas F. Burdick.
@@ -1400,25 +1393,6 @@ WORKAROUND:
   method is applicable, and yet matches neither of the method group
   qualifier patterns.
 
   method is applicable, and yet matches neither of the method group
   qualifier patterns.
 
-341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
-  (from Paul Dietz' test suite)
-
-  CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though
-  that's slightly different) states that these functions perform
-  circular and shared structure detection on their object.  Therefore,
-
-  a.(let ((*print-circle* t))
-      (pprint-linear *standard-output* (let ((x '(a))) (list x x))))
-    should print "(#1=(A) #1#)"
-
-  b.(let ((*print-circle* t))
-      (pprint-linear *standard-output* 
-                     (let ((x (cons nil nil))) (setf (cdr x) x) x)))
-    should print "#1=(NIL . #1#)"
-
-  (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as
-  suggested by the suggested implementation of PPRINT-TABULAR)
-
 343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
   Even the simplest possible overriding of
   COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
 343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
   Even the simplest possible overriding of
   COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
@@ -2096,3 +2070,40 @@ WORKAROUND:
   instruction.  Either the VOP should be fixed or the compiler should be
   taught how to transform this case away, paying particular attention
   to side-effects that might occur in the arguments to ASH.
   instruction.  Either the VOP should be fixed or the compiler should be
   taught how to transform this case away, paying particular attention
   to side-effects that might occur in the arguments to ASH.
+
+384: Compiler runaway on very large character types
+
+  (compile nil '(lambda (x)
+                    (declare (type (member #\a 1) x))
+                    (the (member 1 nil) x)))
+
+  The types apparently normalize into a very large type, and the compiler
+  gets lost in REMOVE-DUPLICATES.  Perhaps the latter should use
+  a better algorithm (one based on hash tables, say) on very long lists
+  when :TEST has its default value?
+
+  A simpler example:
+
+  (compile nil '(lambda (x) (the (not (eql #\a)) x)))
+
+  (partially fixed in 0.9.3.1, but a better representation for these
+   types is needed.)
+
+385:
+  (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
+  (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+
+386: SunOS/x86 stack exhaustion handling broken
+  According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
+  stack exhaustion checking (implemented with a write-protected guard
+  page) does not work on SunOS/x86.
+
+387:
+  12:10 < jsnell> the package-lock test is basically due to a change in the test 
+                  behaviour when you install a handler for error around it. I 
+                  thought I'd disabled the test for now, but apparently that was 
+                  my imagination
+  12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+  12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+  12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+                  ERROR, where it probably shouldn't be