0.8.13.46: More verbosity and a BUG
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index e701579..8fb3dc5 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -156,25 +156,6 @@ WORKAROUND:
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
-45:
-  a slew of floating-point-related errors reported by Peter Van Eynde
-  on July 25, 2000:
-       c: Many expressions generate floating infinity on x86/Linux:
-               (/ 1 0.0)
-               (/ 1 0.0d0)
-               (EXPT 10.0 1000)
-               (EXPT 10.0d0 1000)
-          PVE's regression tests want them to raise errors. sbcl-0.7.0.5
-          on x86/Linux generates the infinities instead. That might or
-          might not be conforming behavior, but it's also inconsistent,
-           which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
-          should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
-          generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
-          signals an error.
-       d: (in section12.erg) various forms a la 
-               (FLOAT 1 DOUBLE-FLOAT-EPSILON)
-          don't give the right behavior.
-
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
   (How should it work properly?)
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
   (How should it work properly?)
@@ -186,6 +167,12 @@ WORKAROUND:
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 
+  (this is apparently mostly fixed on the SPARC and PPC architectures:
+  while giving the backtrace the system complains about "unknown
+  source location: using block start", but apart from that the
+  backtrace seems reasonable.  See tests/debug.impure.lisp for a test
+  case)
+
 64:
   Using the pretty-printer from the command prompt gives funny
   results, apparently because the pretty-printer doesn't know
 64:
   Using the pretty-printer from the command prompt gives funny
   results, apparently because the pretty-printer doesn't know
@@ -209,20 +196,6 @@ WORKAROUND:
   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
   and Pierre Mai.)
 
   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
   and Pierre Mai.)
 
-79:
-  as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
-  The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
-  an easily guessable temporary filename in a way which might open
-  applications using LOAD-FOREIGN to hijacking by malicious users
-  on the same machine. Incantations for doing this safely are
-  floating around the net in various "how to write secure programs
-  despite Unix" documents, and it would be good to (1) fix this in 
-  LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
-  files and make it share the same new safe logic.
-
-  (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
-   make the temporary filename less easily guessable)
-
 83:
   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
 83:
   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
@@ -359,34 +332,6 @@ WORKAROUND:
 
   (see also bug 279)
 
 
   (see also bug 279)
 
-118:
-   as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
-     (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
-        (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
-   when of course it should be NIL. (He says it only fails for X86,
-   not SPARC; dunno about Alpha.)
-
-   Also, "the same problem exists for LONG-FLOAT-EPSILON,
-   DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
-   for the -negative- the + is replaced by a - in the test)."
-
-   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
 124:
    As of version 0.pre7.14, SBCL's implementation of MACROLET makes
    the entire lexical environment at the point of MACROLET available
@@ -461,15 +406,6 @@ WORKAROUND:
   forever, even when it is uninterned and all other references to it
   are lost.
 
   forever, even when it is uninterned and all other references to it
   are lost.
 
-141: "pretty printing and backquote"
-  a.
-    * '``(FOO ,@',@S)
-    ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
-
-  c. (reported by Paul F. Dietz)
-     * '`(lambda ,x)
-     `(LAMBDA (SB-IMPL::BACKQ-COMMA X))
-
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
   prominent SourceForge web/db bug tracking system, which is 
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
   prominent SourceForge web/db bug tracking system, which is 
@@ -537,20 +473,6 @@ WORKAROUND:
 
   This is probably the same bug as 216
 
 
   This is probably the same bug as 216
 
-167:
-  In sbcl-0.7.3.11, compiling the (illegal) code 
-    (in-package :cl-user)
-    (defmethod prove ((uustk uustk))
-      (zap ((frob () nil))
-        (frob)))
-  gives the (not terribly clear) error message
-    ; caught ERROR:
-    ;   (during macroexpansion of (DEFMETHOD PROVE ...))
-    ; can't get template for (FROB NIL NIL)
-  The problem seems to be that the code walker used by the DEFMETHOD
-  macro is unhappy with the illegal syntax in the method body, and
-  is giving an unclear error message.
-
 173:
   The compiler sometimes tries to constant-fold expressions before
   it checks to see whether they can be reached. This can lead to 
 173:
   The compiler sometimes tries to constant-fold expressions before
   it checks to see whether they can be reached. This can lead to 
@@ -978,9 +900,6 @@ WORKAROUND:
                (list x y)))
         (funcall (eval #'foo) 1)))
 
                (list x y)))
         (funcall (eval #'foo) 1)))
 
-269:
-  SCALE-FLOAT should accept any integer for its second argument.
-
 270:
   In the following function constraint propagator optimizes nothing:
 
 270:
   In the following function constraint propagator optimizes nothing:
 
@@ -1021,14 +940,6 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
 
   (fixed in 0.8.2.51, but a test case would be good)
 
-276:
-    (defmethod fee ((x fixnum))
-      (setq x (/ x 2))
-      x)
-    (fee 1) => type error
-
-  (taken from CLOCC)
-
 278:
   a.
     (defun foo ()
 278:
   a.
     (defun foo ()
@@ -1381,13 +1292,13 @@ WORKAROUND:
     (let ((tsos (make-string-output-stream))
           (ssos (make-string-output-stream)))
       (let ((*print-circle* t)
     (let ((tsos (make-string-output-stream))
           (ssos (make-string-output-stream)))
       (let ((*print-circle* t)
-       (*trace-output* tsos)
-       (*standard-output* ssos))
+           (*trace-output* tsos)
+           (*standard-output* ssos))
         (prin1 *tangle* *standard-output*))
       (let ((string (get-output-stream-string ssos)))
         (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
           ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
         (prin1 *tangle* *standard-output*))
       (let ((string (get-output-stream-string ssos)))
         (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
           ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
-          (error "oops: ~S" string))))
+          (error "oops: ~S" string)))))
   It might be straightforward to fix this by turning the
   *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
   per-stream slots, but (1) it would probably be sort of messy faking
   It might be straightforward to fix this by turning the
   *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
   per-stream slots, but (1) it would probably be sort of messy faking
@@ -1428,15 +1339,260 @@ WORKAROUND:
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 
-330: "PARSE-NAMESTRING should accept namestrings as the default argument"
-  (parse-namestring "foo" nil "/") 
-  debugger invoked on a TYPE-ERROR in thread 3138:
-    The value "/" is not of type PATHNAME.
-  According to the PARSE-NAMESTRING dictionary entry the
-  default-pathname parameter can be any pathname designator.
-
 331: "lazy creation of CLOS classes for user-defined conditions"
     (defstruct foo)
     (defstruct (bar (:include foo)))
     (sb-mop:class-direct-subclasses (find-class 'foo))
   returns NIL, rather than a singleton list containing the BAR class.
 331: "lazy creation of CLOS classes for user-defined conditions"
     (defstruct foo)
     (defstruct (bar (:include foo)))
     (sb-mop:class-direct-subclasses (find-class 'foo))
   returns NIL, rather than a singleton list containing the BAR class.
+
+332: "fasl stack inconsistency in structure redefinition"
+  (reported by Tim Daly Jr sbcl-devel 2004-05-06)
+  Even though structure redefinition is undefined by the standard, the
+  following behaviour is suboptimal: running
+    (defun stimulate-sbcl ()
+      (let ((filename (format nil "/tmp/~A.lisp" (gensym))))
+        ;;create a file which redefines a structure incompatibly
+        (with-open-file (f filename :direction :output :if-exists :supersede)
+          (print '(defstruct astruct foo) f)
+          (print '(defstruct astruct foo bar) f))
+        ;;compile and load the file, then invoke the continue restart on
+        ;;the structure redefinition error
+        (handler-bind ((error (lambda (c) (continue c))))
+          (load (compile-file filename)))))
+    (stimulate-sbcl)
+  and choosing the CONTINUE restart yields the message
+    debugger invoked on a SB-INT:BUG in thread 27726:
+      fasl stack not empty when it should be
+
+336: "slot-definitions must retain the generic functions of accessors"
+  reported by Tony Martinez:
+    (defclass foo () ((bar :reader foo-bar)))
+    (defun foo-bar (x) x)
+    (defclass foo () ((bar :reader get-bar))) ; => error, should work
+
+  Note: just punting the accessor removal if the fdefinition
+  is not a generic function is not enough:
+
+   (defclass foo () ((bar :reader foo-bar)))
+   (defvar *reader* #'foo-bar)
+   (defun foo-bar (x) x)
+   (defclass foo () ((bar :initform 'ok :reader get-bar)))
+   (funcall *reader* (make-instance 'foo)) ; should be an error, since
+                                           ; the method must be removed
+                                           ; by the class redefinition
+
+  Fixing this should also fix a subset of #328 -- update the
+  description with a new test-case then.
+
+337: MAKE-METHOD and user-defined method classes
+  (reported by Bruno Haible sbcl-devel 2004-06-11)
+
+  In the presence of  
+
+(defclass user-method (standard-method) (myslot))
+(defmacro def-user-method (name &rest rest)
+  (let* ((lambdalist-position (position-if #'listp rest))
+         (qualifiers (subseq rest 0 lambdalist-position))
+         (lambdalist (elt rest lambdalist-position))
+         (body (subseq rest (+ lambdalist-position 1)))
+         (required-part 
+          (subseq lambdalist 0 (or 
+                                (position-if 
+                                 (lambda (x) (member x lambda-list-keywords))
+                                 lambdalist)
+                                (length lambdalist))))
+         (specializers (mapcar #'find-class 
+                               (mapcar (lambda (x) (if (consp x) (second x) t))
+                                       required-part)))
+         (unspecialized-required-part 
+          (mapcar (lambda (x) (if (consp x) (first x) x)) required-part))
+         (unspecialized-lambdalist 
+          (append unspecialized-required-part 
+           (subseq lambdalist (length required-part)))))
+    `(PROGN
+       (ADD-METHOD #',name
+         (MAKE-INSTANCE 'USER-METHOD
+          :QUALIFIERS ',qualifiers
+          :LAMBDA-LIST ',unspecialized-lambdalist
+          :SPECIALIZERS ',specializers
+          :FUNCTION
+          (LAMBDA (ARGUMENTS NEXT-METHODS-LIST)
+            (FLET ((NEXT-METHOD-P () NEXT-METHODS-LIST)
+                   (CALL-NEXT-METHOD (&REST NEW-ARGUMENTS)
+                     (UNLESS NEW-ARGUMENTS (SETQ NEW-ARGUMENTS ARGUMENTS))
+                     (IF (NULL NEXT-METHODS-LIST)
+                         (ERROR "no next method for arguments ~:S" ARGUMENTS)
+                         (FUNCALL (SB-PCL:METHOD-FUNCTION 
+                                   (FIRST NEXT-METHODS-LIST))
+                                  NEW-ARGUMENTS (REST NEXT-METHODS-LIST)))))
+              (APPLY #'(LAMBDA ,unspecialized-lambdalist ,@body) ARGUMENTS)))))
+       ',name)))
+
+  (progn
+    (defgeneric test-um03 (x))
+    (defmethod test-um03 ((x integer))
+      (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+    (def-user-method test-um03 ((x rational))
+      (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+    (defmethod test-um03 ((x real))
+      (list 'real x (not (null (next-method-p)))))
+    (test-um03 17))
+  works, but
+
+  a.(progn
+      (defgeneric test-um10 (x))
+      (defmethod test-um10 ((x integer))
+        (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um10 ((x rational))
+        (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um10 ((x real))
+        (list 'real x (not (null (next-method-p)))))
+      (defmethod test-um10 :after ((x real)))
+      (def-user-method test-um10 :around ((x integer))
+        (list* 'around-integer x 
+         (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um10 :around ((x rational))
+        (list* 'around-rational x 
+         (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um10 :around ((x real))
+        (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
+      (test-um10 17))
+    fails with a type error, and
+
+  b.(progn
+      (defgeneric test-um12 (x))
+      (defmethod test-um12 ((x integer))
+        (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um12 ((x rational))
+        (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um12 ((x real))
+        (list 'real x (not (null (next-method-p)))))
+      (defmethod test-um12 :after ((x real)))
+      (defmethod test-um12 :around ((x integer))
+        (list* 'around-integer x 
+         (not (null (next-method-p))) (call-next-method)))
+      (defmethod test-um12 :around ((x rational))
+        (list* 'around-rational x 
+         (not (null (next-method-p))) (call-next-method)))
+      (def-user-method test-um12 :around ((x real))
+        (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
+      (test-um12 17))
+    fails with NO-APPLICABLE-METHOD.
+
+339: "DEFINE-METHOD-COMBINATION bugs"
+  (reported by Bruno Haible via the clisp test suite)
+
+  a. Syntax checking laxity (should produce errors):
+     i. (define-method-combination foo :documentation :operator)
+    ii. (define-method-combination foo :documentation nil)
+   iii. (define-method-combination foo nil)
+    iv. (define-method-combination foo nil nil
+         (:arguments order &aux &key))
+     v. (define-method-combination foo nil nil (:arguments &whole))
+    vi. (define-method-combination foo nil nil (:generic-function))
+   vii. (define-method-combination foo nil nil (:generic-function bar baz))
+  viii. (define-method-combination foo nil nil (:generic-function (bar)))
+    ix. (define-method-combination foo nil ((3)))
+     x. (define-method-combination foo nil ((a)))
+
+  b. define-method-combination arguments lambda list badness
+     i. &aux args are currently unsupported;
+    ii. default values of &optional and &key arguments are ignored;
+   iii. supplied-p variables for &optional and &key arguments are not
+        bound.
+
+  c. qualifier matching incorrect
+  (progn
+    (define-method-combination mc27 () 
+        ((normal ()) 
+         (ignored (:ignore :unused)))
+      `(list 'result 
+             ,@(mapcar #'(lambda (method) `(call-method ,method)) normal)))
+    (defgeneric test-mc27 (x)
+      (:method-combination mc27)
+      (:method :ignore ((x number)) (/ 0)))
+    (test-mc27 7))
+
+  should signal an invalid-method-error, as the :IGNORE (NUMBER)
+  method is applicable, and yet matches neither of the method group
+  qualifier patterns.
+
+341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
+  (from Paul Dietz' test suite)
+
+  CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though
+  that's slightly different) states that these functions perform
+  circular and shared structure detection on their object.  Therefore,
+
+  a.(let ((*print-circle* t))
+      (pprint-linear *standard-output* (let ((x '(a))) (list x x))))
+    should print "(#1=(A) #1#)"
+
+  b.(let ((*print-circle* t))
+      (pprint-linear *standard-output* 
+                     (let ((x (cons nil nil))) (setf (cdr x) x) x)))
+    should print "#1=(NIL . #1#)"
+
+  (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as
+  suggested by the suggested implementation of PPRINT-TABULAR)
+
+342: PPRINT-TABULAR / PPRINT-LOGICAL-BLOCK logical block start position
+  The logical block introduced by PPRINT-LOGICAL-BLOCK should not
+  include the prefix, so that
+    (pprint-tabular *standard-output* '(1 2 3) t nil 2)
+  should print
+  "(1 2 3)" rather than "(1  2 3)".
+
+343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
+  Even the simplest possible overriding of
+  COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
+  as "canonical", does not work:
+    (defclass my-generic-function (standard-generic-function) ()
+      (:metaclass funcallable-standard-class))
+    (defmethod compute-discriminating-function ((gf my-generic-function))
+      (let ((dfun (call-next-method)))
+        (lambda (&rest args)
+          (apply dfun args))))
+    (defgeneric foo (x)
+      (:generic-function-class my-generic-function))
+    (defmethod foo (x) (+ x x))
+    (foo 5)
+  signals an error.  This error is the same even if the LAMBDA is
+  replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)).  Maybe the
+  SET-FUNCALLABLE-INSTANCE-FUN scary stuff in
+  src/code/target-defstruct.lisp is broken?  This seems to be broken
+  in CMUCL 18e, so it's not caused by a recent change.
+
+344: more (?) ROOM T problems (possibly part of bug 108)
+  In sbcl-0.8.12.51, and off and on leading up to it, the
+  SB!VM:MEMORY-USAGE operations in ROOM T caused 
+       unhandled condition (of type SB-INT:BUG):
+           failed AVER: "(SAP= CURRENT END)"
+  Several clever people have taken a shot at this without fixing
+  it; this time around (before sbcl-0.8.13 release) I (WHN) just
+  commented out the SB!VM:MEMORY-USAGE calls until someone figures
+  out how to make them work reliably with the rest of the GC.
+
+  (Note: there's at least one dubious thing in room.lisp: see the
+  comment in VALID-OBJ)
+
+345: backtrace on x86 undefined function
+  In sbcl-0.8.13 (and probably earlier versions), code of the form
+    (flet ((test () (#:undefined-fun 42)))
+      (funcall #'test))
+  yields the debugger with a poorly-functioning backtrace.  Brian
+  Downing fixed most of the problems on non-x86 architectures, but on
+  the x86 the backtrace from this evaluation does not reveal anything
+  about the problem.  (See tests in debug.impure.lisp)
+
+346: alpha backtrace
+  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.