0.6.11.10:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 353c71a..db60e3e 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -92,12 +92,6 @@ WORKAROUND:
   Perhaps any number of such consecutive lines ought to turn into a
   single "byte compiling top-level forms:" line.
 
-9:
-  The handling of IGNORE declarations on lambda list arguments of
-  DEFMETHOD is at least weird, and in fact seems broken and useless.
-  I should fix up another layer of binding, declared IGNORABLE, for
-  typed lambda list arguments.
-
 10:
   The way that the compiler munges types with arguments together
   with types with no arguments (in e.g. TYPE-EXPAND) leads to
@@ -110,7 +104,10 @@ WORKAROUND:
   The situation is complicated by the presence of Common Lisp types
   like UNSIGNED-BYTE (which can either be used in list form or alone)
   so I'm not 100% sure that the behavior above is actually illegal.
-  But I'm 90+% sure, and someday perhaps I'll be motivated to look it up..
+  But I'm 90+% sure, and the following related behavior,
+       (TYPEP 11 'AND) => T
+  treating the bare symbol AND as equivalent to '(AND), is specifically
+  forbidden (by the ANSI specification of the AND type).
 
 11:
   It would be nice if the
@@ -138,7 +135,9 @@ WORKAROUND:
   to SBCL, I was looking for complexity to delete, and I thought it was safe
   to just delete support for floating point infinities. It wasn't: they're
   generated by the floating point hardware even when we remove support
-  for them in software. -- WHN] Support for them should be restored.
+  for them in software. Also we claim the :IEEE-FLOATING-POINT feature,
+  and I think that means we should support infinities.-- WHN] Support
+  for them should be restored.
 
 14:
   The ANSI syntax for non-STANDARD method combination types in CLOS is
@@ -245,35 +244,6 @@ WORKAROUND:
   a secondary error "caught ERROR: unrecoverable error during compilation"
   and then return with FAILURE-P true,
 
-25:
-  from CMU CL mailing list 01 May 2000 
-
-I realize I can take care of this by doing (proclaim (ignore pcl::.slots1.))
-but seeing as .slots0. is not-exported, shouldn't it be ignored within the
-+expansion
-when not used?
-In: DEFMETHOD FOO-BAR-BAZ (RESOURCE-TYPE)
-  (DEFMETHOD FOO-BAR-BAZ
-             ((SELF RESOURCE-TYPE))
-             (SETF (SLOT-VALUE SELF 'NAME) 3))
---> BLOCK MACROLET PCL::FAST-LEXICAL-METHOD-FUNCTIONS
---> PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET
---> PCL::BIND-LEXICAL-METHOD-FUNCTIONS LET PCL::BIND-ARGS LET* PCL::PV-BINDING
---> PCL::PV-BINDING1 PCL::PV-ENV LET
-==>
-  (LET ((PCL::.SLOTS0. #))
-    (PROGN SELF)
-    (BLOCK FOO-BAR-BAZ
-      (LET #
-        #)))
-Warning: Variable PCL::.SLOTS0. defined but never used.
-Compilation unit finished.
-  1 warning
-
-#<Standard-Method FOO-BAR-BAZ (RESOURCE-TYPE) {480918FD}>
-
 26:
   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
 
@@ -335,42 +305,6 @@ returning an array as first value always.
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
 
-34:
-  WHN test case: Compile this file:
-    (eval-when (:compile-toplevel :load-toplevel :execute)
-      (defclass a-class () (a)))
-    (defconstant +a-constant+ (make-instance 'a-class))
-    (defconstant +another-constant+ (vector +a-constant+))
-  as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000:
-    $ cat xx.lisp
-    (defconstant +a-constant+ (make-instance 'a-class))
-    (defconstant +another-constant+ (vector +a-constant+))
-    $ lisp
-    CMU Common Lisp release x86-linux 2.4.19  8 February 2000 build 456,
-    running on
-    bobby
-    Send bug reports and questions to your local CMU CL maintainer,
-    or to pvaneynd@debian.org
-    or to cmucl-help@cons.org. (prefered)
-    type (help) for help, (quit) to exit, and (demo) to see the demos
-    Loaded subsystems:
-      Python 1.0, target Intel x86
-      CLOS based on PCL version:  September 16 92 PCL (f)
-    * (defclass a-class () ())
-    #<STANDARD-CLASS A-CLASS {48027BD5}>
-    * (compile-file "xx.lisp")
-    Python version 1.0, VM version Intel x86 on 12 JUN 00 08:12:55 am.
-    Compiling:
-    /home/strandh/Research/Functional/Common-Lisp/CLIM/Development/McCLIM
-    /xx.lisp 12 JUN 00 07:47:14 am
-    Compiling Load Time Value of (PCL::GET-MAKE-INSTANCE-FUNCTION-SYMBOL
-    '(A-CLASS NIL NIL)):
-    Byte Compiling Top-Level Form:
-    Error in function C::DUMP-STRUCTURE:  Attempt to dump invalid
-    structure:
-      #<A-CLASS {4803A5B5}>
-    How did this happen?
-
 35:
   The compiler assumes that any time a function of declared FTYPE
   doesn't signal an error, its arguments were of the declared type.
@@ -406,26 +340,6 @@ returning an array as first value always.
   accepting &REST even when it's not followed by an argument name:
        (DEFMETHOD FOO ((X T) &REST) NIL)
 
-39:
-  On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote
-
-  Hannu Rummukainen wrote:
-  ...
-  > There's something weird going on with the compilation of the attached
-  > code.  Compiling and loading the file in a fresh lisp, then invoking
-  > (test-it) gives
-  Thanks for the bug report, nice to have this one fixed. It was a bug
-  in the x86 backend, the < VOP. A fix has been committed to the main
-  source, see the file compiler/x86/float.lisp.
-
-  Probably the same bug exists in SBCL.
-
-40:
-  TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel,
-  so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET))
-  returns (VALUES T T). Probably it should be an error instead,
-  complaining that the type SOMETHING-NOT-DEFINED-YET is not defined.
-
 41:
   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
        (DEFTYPE INDEXOID () '(INTEGER 0 1000))
@@ -844,17 +758,59 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
   WITH-OUTPUT-TO-STRING.
 
-77:
-  As reported by Martin Atzmueller on sbcl-devel 2000-01-09,
-  DEF-ALIEN-VARIABLE doesn't work. With either the example in the
-  old CMU CL docs,
-    (def-alien-variable "errno" integer)
-  or another test avoiding any peculiarities of modern errno-as-macro
-  implementations,
-    (def-alien-variable "from_space" integer)
-  in sbcl-0.6.9 the operation fails with 
-    TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
-      NIL is not of type SB-KERNEL:LEXENV.
+78:
+  ANSI says in one place that type declarations can be abbreviated even
+  when the type name is not a symbol, e.g.
+    (DECLAIM ((VECTOR T) *FOOVECTOR*))
+  SBCL doesn't support this. But ANSI says in another place that this
+  isn't allowed. So it's not clear this is a bug after all. (See the
+  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.
+
+80:
+  (fixed early Feb 2001 by MNA)
+
+81:
+  As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
+  2001-02-14, 
+    According to CLHS
+        (loop with (a . b) of-type float = '(0.0 . 1.0)
+          and (c . d) of-type float = '(2.0 . 3.0)
+          return (list a b c d))
+    should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
+    invokes the debugger: "B is not of type list".
+  SBCL does the same thing.
+
+82: 
+  Functions are assigned names based on the context in which they're
+  defined. This is less than ideal for the functions which are
+  used to implement CLOS methods. E.g. the output of 
+  (DESCRIBE 'PRINT-OBJECT) lists functions like 
+       #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}> 
+  and
+       #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
+  It would be better if these functions' names always identified
+  them as methods, and identified their generic functions and
+  specializers.
+
+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
+  the mean of the distribution can be systematically O(0.1%) wrong.
+  Just increasing R-I-E-B is probably not a good solution, since
+  it would decrease efficiency more than is probably necessary. Perhaps
+  using some sort of accept/reject method would be better.
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER