collect `(array ,(sb-vm:saetp-specifier x)))))
=> NIL, T (when it should be T, T)
-308: "Characters without names"
- (reported by Bruno Haible sbcl-devel "character names are missing"
- 2004-04-19)
- (graphic-char-p (code-char 255))
- => NIL
- (char-name (code-char 255))
- => NIL
-
- SBCL is unsure of what to do about characters with codes in the
- range 128-255. Currently they are treated as non-graphic, but don't
- have names, which is not compliant with the standard. Various fixes
- are possible, such as
- * giving them names such as NON-ASCII-128;
- * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular);
- * making the characters graphic (makes a certain amount of sense);
- * biting the bullet and implementing Unicode (probably quite hard).
-
309: "Dubious values for implementation limits"
(reported by Bruno Haible sbcl-devel "Incorrect value of
multiple-values-limit" 2004-04-19)
318: "stack overflow in compiler warning with redefined class"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
test suite.
- (setq *print-pretty* nil)
(defstruct foo a)
(setf (find-class 'foo) nil)
(defstruct foo slot-1)
- gives
- ...#<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTUREControl stack guard page temporarily disabled: proceed with caution
- (it's not really clear what it should give: is (SETF FIND-CLASS)
- meant to be enough to delete structure classes from the system?
- Giving a stack overflow is definitely suboptimal, though.)
+ This used to give a stack overflow from within the printer, which has
+ been fixed as of 0.8.16.11. Current result:
+ ; caught ERROR:
+ ; can't compile TYPEP of anonymous or undefined class:
+ ; #<SB-KERNEL:STRUCTURE-CLASSOID FOO>
+ ...
+ debugger invoked on a TYPE-ERROR in thread 19973:
+ The value NIL is not of type FUNCTION.
+
+ CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS)
+ meant to be enough to delete structure classes from the system?
319: "backquote with comma inside array"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
In sbcl-0.8.13, all backtraces from errors caused by internal errors
on the alpha seem to have a "bogus stack frame".
-347: FUNCALL forms and compiler-macros
- (reported by Johan Bockgård on #lisp)
- The example
- (funcall (compiler-macro-function 'square) '(funcall #'square x) nil)
- => (EXPT X 2)
- from CLHS entry for DEFINE-COMPILER-MACRO fails in 0.8.13.41 with an
- error. Fixed in CMUCL 19a.
-
348:
Structure slot setters do not preserve evaluation order:
(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.