+
+344: more (?) ROOM T problems (possibly part of bug 108)
+ In sbcl-0.8.12.51, and off and on leading up to it, the
+ SB!VM:MEMORY-USAGE operations in ROOM T caused
+ unhandled condition (of type SB-INT:BUG):
+ failed AVER: "(SAP= CURRENT END)"
+ Several clever people have taken a shot at this without fixing
+ it; this time around (before sbcl-0.8.13 release) I (WHN) just
+ commented out the SB!VM:MEMORY-USAGE calls until someone figures
+ out how to make them work reliably with the rest of the GC.
+
+ (Note: there's at least one dubious thing in room.lisp: see the
+ comment in VALID-OBJ)
+
+345: backtrace on x86 undefined function
+ In sbcl-0.8.13 (and probably earlier versions), code of the form
+ (flet ((test () (#:undefined-fun 42)))
+ (funcall #'test))
+ yields the debugger with a poorly-functioning backtrace. Brian
+ Downing fixed most of the problems on non-x86 architectures, but on
+ the x86 the backtrace from this evaluation does not reveal anything
+ about the problem. (See tests in debug.impure.lisp)
+
+346: alpha backtrace
+ In sbcl-0.8.13, all backtraces from errors caused by internal errors
+ on the alpha seem to have a "bogus stack frame".
+
+348:
+ Structure slot setters do not preserve evaluation order:
+
+ (defstruct foo (x))
+
+ (let ((i (eval '-2))
+ (x (make-foo)))
+ (funcall #'(setf foo-x)
+ (incf i)
+ (aref (vector x) (incf i)))
+ (foo-x x))
+ => error
+
+349: PPRINT-INDENT rounding implementation decisions
+ At present, pprint-indent (and indeed the whole pretty printer)
+ more-or-less assumes that it's using a monospace font. That's
+ probably not too silly an assumption, but one piece of information
+ the current implementation loses is from requests to indent by a
+ non-integral amount. As of sbcl-0.8.15.9, the system silently
+ truncates the indentation to an integer at the point of request, but
+ maybe the non-integral value should be propagated through the
+ pprinter and only truncated at output? (So that indenting by 1/2
+ then 3/2 would indent by two spaces, not one?)
+
+350: heap overflow when printing bignums
+ (reported by Bruno Haible 2004-10-08)
+ In sbcl-0.8.15.18,
+ * (DEFPARAMETER *BIG* (ASH 1 1000000))
+ *BIG*
+ * (PRINT *BIG*)
+ Argh! gc_find_freeish_pages failed (restart_page), nbytes=110152.
+ It should be straightforward to push the heap overflow threshold
+ up to much larger bignums; Paul Dietz pointed out it would help to
+ use a bignum-printing algorithm which bisected the printed number,
+ rather than stripping off digits one by one, and CSR suggested using
+ iteration rather than recursion to encourage intermediate results
+ to be GCed.
+
+351: suboptimal error handling/reporting when compiling (PUSH (LET ...))
+ In sbcl-0.8.15.18,
+ * (defvar *b*)
+ *B*
+ * (defun oops ()
+ (push *b*
+ (let ((b *b*))
+ (aref b 1))))
+ causes the compiler to die with a TYPE-ERROR in SB-C::EXTRACT-LET-VARS,
+ The value #:G4 is not of type LIST.
+ Since the (LET ...) expression is being misused in PUSH as a
+ SETFable place, it would be more helpful to fail as in
+ * (defun oops2 () (setf (let ((b *b*)) (aref b 1)) *b*))
+ with compilation errors and warnings like
+ ; in: LAMBDA NIL
+ ; ((B *B*))
+ ; caught ERROR:
+ ; illegal function call
+ and
+ ; caught WARNING:
+ ; The function (SETF LET) is undefined, and its name is reserved
+ ; by ANSI CL so that even if it were defined later, the code
+ ; doing so would not be portable.