X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=d16501c0b7d452343b4a384a271fc7d70dcd828e;hb=96a1badea2523bf188f7ba023e2f69a6785847d6;hp=35172a69aa2049aa4f28db773a6180577ceb662f;hpb=18811631b81a9e7d4270c44896483199f3b7c7ac;p=sbcl.git

diff --git a/BUGS b/BUGS
index 35172a6..d16501c 100644
--- a/BUGS
+++ b/BUGS
@@ -382,6 +382,20 @@ WORKAROUND:
    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
@@ -722,7 +736,6 @@ WORKAROUND:
   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
@@ -1209,18 +1222,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
@@ -1295,24 +1296,6 @@ WORKAROUND:
                collect `(array ,(sb-vm:saetp-specifier x)))))
     => NIL, T (when it should be T, T)
 
-307: "Problem in obsolete instance protocol"
-    (reported by Bruno Haible as the fourth problem in sbcl-devel 
-    "installing sbcl" 2004-04-15)
-
-  (progn
-    (defclass foo92b (foo92a) ((s :initarg :s)))
-    (defclass foo92a () ())
-    (let ((x (make-instance 'foo92b :s 5)) (update-counter 0))
-      (defclass foo92b (foo92a) ((s) (s1) (s2))) ; still subclass of foo92a
-      (slot-value x 's)
-      (defmethod update-instance-for-redefined-class 
-          ((object foo92b) added-slots discarded-slots plist &rest initargs)
-        (incf update-counter))
-      (make-instances-obsolete 'foo92a)
-      (slot-value x 's)
-      update-counter))
-  => 0 ; should be 1
-
 308: "Characters without names"
     (reported by Bruno Haible sbcl-devel "character names are missing"
     2004-04-19)
@@ -1340,35 +1323,6 @@ WORKAROUND:
   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.
-
 311: "Tokeniser not thread-safe"
     (see also Robert Marlow sbcl-help "Multi threaded read chucking a
     spak" 2004-04-19)
@@ -1388,5 +1342,117 @@ WORKAROUND:
 
   (probably related to the bug 280.)
 
-313: "source-transforms are Lisp-1"
-  (fixed in 0.8.10.2)
+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.
+
+325: "CLOSE :ABORT T on supeseding streams"
+  Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
+  file on disk, even if one existed before opening.
+
+  The illegality of this is not crystal clear, as the ANSI dictionary
+  entry for CLOSE says that when :ABORT is T superseded files are not
+  superseded (ie. the original should be restored), whereas the OPEN
+  entry says about :IF-EXISTS :SUPERSEDE "If possible, the
+  implementation should not destroy the old file until the new stream
+  is closed." -- implying that even though undesirable, early deletion
+  is legal. Restoring the original would none the less be the polite
+  thing to do.