0.9.14.8:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 4860f07..fd35ada 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -900,7 +900,7 @@ WORKAROUND:
   strongly suspected problems, as of 0.8.3.10: please update this
   bug instead of creating new ones
 
-    localtime() - called for timezone calculations in code/time.lisp
+    gethostbyname, gethostbyaddr in sb-bsd-sockets
 
 284: Thread safety: special variables
   There are lots of special variables in SBCL, and I feel sure that at
@@ -2129,5 +2129,69 @@ WORKAROUND:
   For some more details see comments for (define-alien-type-method
   (c-string :deport-gen) ...)  in host-c-call.lisp.
 
-401: "optimizer runaway on bad constant type specifiers in TYPEP"
-  (fixed in 0.9.12.12)
+402: "DECLAIM DECLARATION does not inform the PCL code-walker"
+  reported by Vincent Arkesteijn:
+
+  (declaim (declaration foo))
+  (defgeneric bar (x))
+  (defmethod bar (x)
+    (declare (foo x))
+    x)
+
+  ==> WARNING: The declaration FOO is not understood by
+      SB-PCL::SPLIT-DECLARATIONS.
+      Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
+      SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
+      SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
+      (Assuming it is a variable declaration without argument).
+
+403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
+  In sbcl-0.9.13.34,
+    (defparameter *c*
+      (make-condition 'simple-error
+                      :format-control "ow... ~S"
+                      :format-arguments '(#1=(#1#))))
+    (setf *print-circle* t *print-level* 4)
+    (format nil "~@<~A~:@>" *c*)
+  gives
+    "ow... (((#)))"
+  where I (WHN) believe the correct result is "ow... #1=(#1#)",
+  like the result from (PRINC-TO-STRING *C*). The question of 
+  what the correct result is is complicated by the hairy text in 
+  the Hyperspec "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
+    Other than the difference in its argument, ~@<...~:> is 
+    exactly the same as ~<...~:> except that circularity detection 
+    is not applied if ~@<...~:> is encountered at top level in a 
+    format string.
+  But because the odd behavior happens even without the at-sign, 
+    (format nil "~<~A~:@>" (list *c*)) ; => "ow... (((#)))"
+  and because something seemingly similar can happen even in 
+  PPRINT-LOGICAL-BLOCK invoked directly without FORMAT, 
+    (pprint-logical-block (*standard-output* '(some nonempty list))
+      (format *standard-output* "~A" '#1=(#1#)))
+  (which prints "(((#)))" to *STANDARD-OUTPUT*), I don't think 
+  that the 22.3.5.2 trickiness is fundamental to the problem.
+
+  My guess is that the problem is related to the logic around the MODE
+  argument to CHECK-FOR-CIRCULARITY, but I haven't reverse-engineered
+  enough of the intended meaning of the different MODE values to be
+  confident of this.
+
+404: nonstandard DWIMness in LOOP with unportably-ordered clauses
+  In sbcl-0.9.13, the code
+    (loop with stack = (make-array 2 :fill-pointer 2 :initial-element t)
+          for length = (length stack)
+          while (plusp length)
+          for element = (vector-pop stack)
+          collect element)
+  compiles without error or warning and returns (T T). Unfortunately, 
+  it is inconsistent with the ANSI definition of the LOOP macro, 
+  because it mixes up VARIABLE-CLAUSEs with MAIN-CLAUSEs. Furthermore,
+  SBCL's interpretation of the intended meaning is only one possible,
+  unportable interpretation of the noncompliant code; in CLISP 2.33.2, 
+  the code compiles with a warning
+    LOOP: FOR clauses should occur before the loop's main body
+  and then fails at runtime with 
+    VECTOR-POP: #() has length zero
+  perhaps because CLISP has shuffled the clauses into an 
+  ANSI-compliant order before proceeding.