Raymond Toy comments that this is tricky on the X86 since its FPU
uses 80-bit precision internally.
+ Bruno Haible comments:
+ The values are those that are expected for an IEEE double-float
+ arithmetic. The problem appears to be that the rounding is not
+ IEEE on x86 compliant: namely, values are first rounded to 64
+ bits mantissa precision, then only to 53 bits mantissa
+ precision. This gives different results than rounding to 53 bits
+ mantissa precision in a single step.
+
+ The quick "fix", to permanently change the FPU control word from
+ 0x037f to 0x027f, will give problems with the fdlibm code that is
+ used for computing transcendental functions like sinh() etc.
+ so maybe we need to change the FPU control word to that for Lisp
+ code, and adjust it to the safe 0x037f for calls to C?
+
124:
As of version 0.pre7.14, SBCL's implementation of MACROLET makes
the entire lexical environment at the point of MACROLET available
all of the arguments are circular is probably desireable).
213: "Sequence functions and type checking"
- a. (fixed in 0.8.4.36)
b. MAP, when given a type argument that is SUBTYPEP LIST, does not
check that it will return a sequence of the given type. Fixing
it along the same lines as the others (cf. work done around
; The variable Y is defined but never used.
245: bugs in disassembler
- a. On X86 an immediate operand for IMUL is printed incorrectly.
b. On X86 operand size prefix is not recognized.
251:
successive adds of integers to double-floats produces double-floats,
so none of the type restrictions in the code is violated.
-298: (aka PFD MISC.183)
- Compiler fails on
-
- (defun foo ()
- (multiple-value-call #'bar
- (ext)
- (catch 'tag (return-from foo (int)))))
-
- This program violates "unknown values LVAR stack discipline": if INT
- returns, values returned by (EXT) must be removed from under that of
- (INT).
-
300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
argument type only after having read a character. This is caused
with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
(1+ (fee)))
uses generic arithmetic with INLINE and fixnum without.
+
+306: "Imprecise unions of array types"
+ a.(defun foo (x)
+ (declare (optimize speed)
+ (type (or (array cons) (array vector)) x))
+ (elt (aref x 0) 0))
+ (foo #((0))) => TYPE-ERROR
+
+ relatedly,
+
+ b.(subtypep
+ 'array
+ `(or
+ ,@(loop for x across sb-vm:*specialized-array-element-type-properties*
+ 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)
+ (values-list (make-list 1000000)), on x86/linux, signals a stack
+ exhaustion condition, despite MULTIPLE-VALUES-LIMIT being
+ significantly larger than 1000000. There are probably similar
+ dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp
+ around the same time regarding a call to LIST on sparc with 1000
+ arguments) and other implementation limit constants.
+
+311: "Tokeniser not thread-safe"
+ (see also Robert Marlow sbcl-help "Multi threaded read chucking a
+ spak" 2004-04-19)
+ The tokenizer's use of *read-buffer* and *read-buffer-length* causes
+ spurious errors should two threads attempt to tokenise at the same
+ time.
+
+312:
+ (reported by Jon Dyte)
+ SBCL issues a warning "Duplicate definition of FOO" compiling
+
+ (declaim (inline foo))
+ (defun foo (x)
+ (1+ x))
+ (defun bar (y)
+ (list (foo y) (if (> y 1) (funcall (if (> y 0) #'foo #'identity) y))))
+
+ (probably related to the bug 280.)
+
+314: "LOOP :INITIALLY clauses and scope of initializers"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite, originally by Thomas F. Burdick.
+ ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
+ ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is
+ ;; initialized to the result of evaluating form1. 6.1.7.2 says that
+ ;; initially clauses are evaluated in the loop prologue, which precedes all
+ ;; loop code except for the initial settings provided by with, for, or as.
+ (loop :for x = 0 :then (1+ x)
+ :for y = (1+ x) :then (ash y 1)
+ :for z :across #(1 3 9 27 81 243)
+ :for w = (+ x y z)
+ :initially (assert (zerop x)) :initially (assert (= 2 w))
+ :until (>= w 100) :collect w)
+ Expected: (2 6 15 38)
+ Got: ERROR
+
+315: "no bounds check for access to displaced array"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (locally (declare (optimize (safety 3) (speed 0)))
+ (let* ((x (make-array 10 :fill-pointer 4 :element-type 'character
+ :initial-element #\space :adjustable t))
+ (y (make-array 10 :fill-pointer 4 :element-type 'character
+ :displaced-to x)))
+ (adjust-array x '(5))
+ (char y 5)))
+
+ SBCL 0.8.10 elides the bounds check somewhere along the line, and
+ returns #\Nul (where an error would be much preferable, since a test
+ of that form but with (setf (char y 5) #\Space) potentially corrupts
+ the heap and certainly confuses the world if that string is used by
+ C code.
+
+317: "FORMAT of floating point numbers"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (format nil "~1F" 10) => "0." ; "10." expected
+ (format nil "~0F" 10) => "0." ; "10." expected
+ (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
+ it would be nice if whatever fixed this also untangled the two
+ competing implementations of floating point printing (Steele and
+ White, and Burger and Dybvig) present in src/code/print.lisp
+
+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.)
+
+319: "backquote with comma inside array"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (read-from-string "`#1A(1 2 ,(+ 2 2) 4)")
+ gives
+ #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
+ which probably isn't intentional.
+
+321: "DEFINE-METHOD-COMBINATION lambda list parsing"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (define-method-combination w-args ()
+ ((method-list *))
+ (:arguments arg1 arg2 &aux (extra :extra))
+ `(progn ,@(mapcar (lambda (method) `(call-method ,method)) method-list)))
+ gives a (caught) compile-time error, which can be exposed by
+ (defgeneric mc-test-w-args (p1 p2 s)
+ (:method-combination w-args)
+ (:method ((p1 number) (p2 t) s)
+ (vector-push-extend (list 'number p1 p2) s))
+ (:method ((p1 string) (p2 t) s)
+ (vector-push-extend (list 'string p1 p2) s))
+ (:method ((p1 t) (p2 t) s) (vector-push-extend (list t p1 p2) s)))
+
+323: "REPLACE, BIT-BASH and large strings"
+ The transform for REPLACE on simple-base-strings uses BIT-BASH, which
+ at present has an upper limit in size. Consequently, in sbcl-0.8.10
+ (defun foo ()
+ (declare (optimize speed (safety 1)))
+ (let ((x (make-string 140000000))
+ (y (make-string 140000000)))
+ (length (replace x y))))
+ (foo)
+ gives
+ debugger invoked on a TYPE-ERROR in thread 2412:
+ The value 1120000000 is not of type (MOD 536870911).
+ (see also "more and better sequence transforms" sbcl-devel 2004-05-10)
+
+324: "STREAMs and :ELEMENT-TYPE with large bytesize"
+ In theory, (open foo :element-type '(unsigned-byte <x>)) should work
+ for all positive integral <x>. At present, it only works for <x> up
+ to about 1024 (and similarly for signed-byte), so
+ (open "/dev/zero" :element-type '(unsigned-byte 1025))
+ gives an error in sbcl-0.8.10.
projects / sbcl.git / blobdiff