X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=e2c7ca7d14425704738291cd9ec9baeb136f9168;hb=fb9c34275389e23f32d80954ab4848fac48936d9;hp=e3bb4d525f6db876394ac31ee20f3d032f546f94;hpb=b282ecc0240c6dc67aaeea2d64046d411738385a;p=sbcl.git

diff --git a/BUGS b/BUGS
index e3bb4d5..e2c7ca7 100644
--- a/BUGS
+++ b/BUGS
@@ -882,7 +882,6 @@ WORKAROUND:
   ;   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:
@@ -1210,18 +1209,6 @@ WORKAROUND:
   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
@@ -1279,3 +1266,100 @@ WORKAROUND:
       (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.
+
+310: "Floating point printing inaccuracy"
+    (reported by Bruno Haible sbcl-devel "print-read consistency for 
+    floating point numbers" 2004-04-19)
+  (let ((x (/ -9.349640046247849d-21 -9.381494249123696d-11)))
+    (let ((y (read-from-string (write-to-string x :readably t))))
+      (eql x y)))
+  should return T but, as of sbcl-0.8.9.51, returns NIL.
+
+  That this is a bug in the printer is demonstrated by
+    (setq x1 (float -5496527/100000000000000000))
+    (setq x2 (float -54965272/1000000000000000000))
+    (integer-decode-float x1) => 15842660 -58 -1
+    (integer-decode-float x2) => 15842661 -58 -1
+    (prin1-to-string x1) => "-5.496527e-11"
+    (prin1-to-string x2) => "-5.496527e-11" ; should be different!
+
+  Note also the following comment from src/code/print.lisp:
+    ;;; NOTE: When a number is to be printed in exponential format, it is
+    ;;; scaled in floating point. Since precision may be lost in this
+    ;;; process, the guaranteed accuracy properties of FLONUM-TO-STRING
+    ;;; are lost. The difficulty is that FLONUM-TO-STRING performs
+    ;;; extensive computations with integers of similar magnitude to that
+    ;;; of the number being printed. For large exponents, the bignums
+    ;;; really get out of hand. If bignum arithmetic becomes reasonably
+    ;;; fast and the exponent range is not too large, then it might become
+    ;;; attractive to handle exponential notation with the same accuracy
+    ;;; as non-exponential notation, using the method described in the
+    ;;; Steele and White paper.
+
+  See also CSR sbcl-devel with an implementation of Berger and
+  Dybvig's algorithm for printing and a fix for reading.
+
+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.)
+
+313: "source-transforms are Lisp-1"
+  (fixed in 0.8.10.2)