+
+325: "CLOSE :ABORT T on supeseding streams"
+ Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
+ file on disk, even if one existed before opening.
+
+ The illegality of this is not crystal clear, as the ANSI dictionary
+ entry for CLOSE says that when :ABORT is T superseded files are not
+ superseded (ie. the original should be restored), whereas the OPEN
+ entry says about :IF-EXISTS :SUPERSEDE "If possible, the
+ implementation should not destroy the old file until the new stream
+ is closed." -- implying that even though undesirable, early deletion
+ is legal. Restoring the original would none the less be the polite
+ thing to do.
+
+326: "*PRINT-CIRCLE* crosstalk between streams"
+ In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be
+ mixed between streams when output operations are intermingled closely
+ enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the
+ test case below), so that e.g. the references #2# appears on a stream
+ with no preceding #2= on that stream to define it (because the #2= was
+ sent to another stream).
+ (cl:in-package :cl-user)
+ (defstruct foo index)
+ (defparameter *foo* (make-foo :index 4))
+ (defstruct bar)
+ (defparameter *bar* (make-bar))
+ (defparameter *tangle* (list *foo* *bar* *foo*))
+ (defmethod print-object ((foo foo) stream)
+ (let ((index (foo-index foo)))
+ (format *trace-output*
+ "~&-$- emitting FOO ~D, ambient *BAR*=~S~%"
+ index *bar*)
+ (format stream "[FOO ~D]" index))
+ foo)
+ (let ((tsos (make-string-output-stream))
+ (ssos (make-string-output-stream)))
+ (let ((*print-circle* t)
+ (*trace-output* tsos)
+ (*standard-output* ssos))
+ (prin1 *tangle* *standard-output*))
+ (let ((string (get-output-stream-string ssos)))
+ (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
+ ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
+ (error "oops: ~S" string))))
+ It might be straightforward to fix this by turning the
+ *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
+ per-stream slots, but (1) it would probably be sort of messy faking
+ up the special variable binding semantics using UNWIND-PROTECT and
+ (2) it might be sort of a pain to test that no other bugs had been
+ introduced.
+
+327: "Lazy construction of CLOS classes from system classoids"
+ In a fresh SBCL,
+ (sb-mop:class-direct-subclasses (find-class 'pathname))
+ returns NIL, despite the LOGICAL-PATHNAME class existing. However,
+ if we then do (find-class 'logical-pathname) and repeat the request
+ for direct subclasses, a list of the logical pathname class is
+ returned. (Though this particular example revealed the problem to
+ CSR, others have found that this gave consistent results for
+ PATHNAME, but not for SIMPLE-CONDITION.)
+
+ Presumably the CLOS bootstrap process needs to iterate over
+ classoids (both structure- and condition-) to create CLOS classes
+ for them, so that this internal inconsistency does not arise? How
+ does this interact with the classoid hierarchy not perfectly
+ mirroring the class hierarchy? (e.g. INSTANCE?)