229:
(subtypep 'function '(function)) => nil, t.
-231: "SETQ does not correctly check the type of a variable being set"
- b.
- (defun foo (x z)
- (declare (type integer x))
- (locally (declare (type (real 1) x))
- (setq x z))
- (list x z))
- (foo 0 0) => (0 0).
-
- (fixed in 0.7.12.8)
-
233: bugs in constraint propagation
a.
(defun foo (x)
(+ x 2)))
(foo 1d0 5) => segmentation violation
-234:
- (fixed in sbcl-0.7.10.36)
-
235: "type system and inline expansion"
a.
(declaim (ftype (function (cons) number) acc))
compiler gets its hands on the code needing compilation from the REPL,
it has been macroexpanded several times.
-239:
- Since 0.7.0:
- (defun foo (bit-array-2 &optional result-bit-array)
- (declare (type (array bit) bit-array-2)
- (type (or (array bit) (member t nil)) result-bit-array))
- (unless (simple-bit-vector-p bit-array-2)
- (multiple-value-call
- (lambda (data1 start1)
- (multiple-value-call
- (lambda (data2 start2)
- (multiple-value-call
- (lambda (data3 start3)
- (declare (ignore start3))
- (print (list data1 data2)))
- (values 0 0)))
- (values bit-array-2 0)))
- (values 444 0))))
-
- Then (foo (make-array 4 :element-type 'bit :adjustable t) nil)
- must return the same value as it prints, but it returns random garbage.
-
-240:
- "confused lexical/special warnings in MULTIPLE-VALUE-BIND"
- (from tonyms on #lisp IRC 2003-02-25)
- In sbcl-0.7.12.55, compiling
- (cl:in-package :cl-user)
- (defvar *foo* 0)
- (defvar *bar* 1)
- (defun bar ()
- (multiple-value-bind (*foo* *bar*) 'eleventy-one
- (bletch)))
- (defun bletch () (format t "~&*FOO*=~S *BAR*=~S" *foo* *bar*))
- (bar)
- gives warnings like "using the lexical binding of the symbol *FOO*"
- even though LOADing the fasl file shows that in fact the special
- bindings are being used.
-
-241:
- "DEFCLASS mysteriously remembers uninterned accessor names."
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
(from tonyms on #lisp IRC 2003-02-25)
In sbcl-0.7.12.55, typing
(defclass foo () ((bar :accessor foo-bar)))
So it's somehow checking the uninterned old accessor name instead
of the new requested accessor name, which seems broken to me (WHN).
+242: "WRITE-SEQUENCE suboptimality"
+ (observed from clx performance)
+ In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
+ (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+ (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+ rather than writing the sequence in one go, leading to severe
+ performance degradation.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.