X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fd35adacef5297b408a28a1a72dee8686f308aea;hb=01e9e8c568777d6480699e6cb3947f38c3bed350;hp=01bae8dc69d5cd4433e72a05ac7dcccada946d9d;hpb=992e6a70a0cae3f6d43bdbba18f77306fdf10662;p=sbcl.git diff --git a/BUGS b/BUGS index 01bae8d..fd35ada 100644 --- 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,9 +2129,6 @@ 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: @@ -2148,3 +2145,53 @@ WORKAROUND: 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.