X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=inline;f=BUGS;h=68cbee7b93df6dc0b501da71d5db4f41c0c63e83;hb=4fc9d21ae1d8a6a2f8ff70f589d5da103203de13;hp=b50388f3a757f829cfed8bc3bdb60e3fc307fee2;hpb=f188d1c6cdcb9d9aa117baf617c70a2933fa1c60;p=sbcl.git

diff --git a/BUGS b/BUGS
index b50388f..68cbee7 100644
--- a/BUGS
+++ b/BUGS
@@ -92,21 +92,6 @@ WORKAROUND:
   Perhaps any number of such consecutive lines ought to turn into a
   single "byte compiling top-level forms:" line.
 
-8:
-  Compiling a file containing the erroneous program
-	(DEFSTRUCT FOO
-	  A
-	  B)
-	(DEFSTRUCT (BAR (:INCLUDE FOO))
-	  A
-	  B)
-  gives only the not-very-useful message
-	caught ERROR:
-	  (during macroexpansion)
-	Condition PROGRAM-ERROR was signalled.
-  (The specific message which says that the problem was duplicate
-  slot names gets lost.)
-
 9:
   The handling of IGNORE declarations on lambda list arguments of
   DEFMETHOD is at least weird, and in fact seems broken and useless.
@@ -188,39 +173,6 @@ WORKAROUND:
   (Also, when this is fixed, we can enable the code in PROCLAIM which 
   checks for incompatible FTYPE redeclarations.)
 
-16:
-  The ANSI spec says that CONS can be a compound type spec, e.g.
-  (CONS FIXNUM REAL). SBCL doesn't support this.
-
-17:
-  from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000:
-I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical
-pathname, the type of the corresponding compiled file is X86F:
-	* (compile-file "/home/paolo/lisp/tools/foo")
-	Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm.
-	Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
-	Converted SQUARE.
-	Compiling DEFUN SQUARE:
-	Byte Compiling Top-Level Form:
-	/home/paolo/lisp/tools/foo.x86f written.
-	Compilation finished in 0:00:00.
-	#p"/home/paolo/lisp/tools/foo.x86f"
-	NIL
-	NIL
-But when the function is called with a logical pathname, the file type
-becomes FASL:
-	* (compile-file "tools:foo")
-	Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm.
-	Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
-	Converted SQUARE.
-	Compiling DEFUN SQUARE:
-	Byte Compiling Top-Level Form:
-	TOOLS:FOO.FASL written.
-	Compilation finished in 0:00:00.
-	#p"/home/paolo/lisp/tools/foo.fasl"
-	NIL
-	NIL
-
 18:
   from DTC on the CMU CL mailing list 25 Feb 2000:
 ;;; Compiler fails when this file is compiled.
@@ -353,11 +305,6 @@ returning an array as first value always.
    The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
   This is still present in sbcl-0.6.8.
 
-30:
-  The CMU CL reader code takes liberties in binding the standard read table
-  when reading the names of characters. Tim Moore posted a patch to the 
-  CMU CL mailing list Mon, 22 May 2000 21:30:41 -0700.
-
 31:
   In some cases the compiler believes type declarations on array
   elements without checking them, e.g.
@@ -389,6 +336,11 @@ returning an array as first value always.
   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))
@@ -449,91 +401,19 @@ returning an array as first value always.
   make sense to add another flag (CHECKED?) to DEFKNOWN to 
   identify functions which *do* check their argument types.)
 
-36:
-  As pointed out by Martin Cracauer on the CMU CL mailing list
-  13 Jun 2000, the :FILE-LENGTH operation for 
-  FD-STREAM-MISC-ROUTINE is broken for large files: it says
-  (THE INDEX SIZE) even though SIZE can be larger than INDEX.
-
-37:
-  In SBCL 0.6.5 (and CMU CL 18b) compiling and loading
-	(in-package :cl-user)
-	(declaim (optimize (safety 3)
-			   (debug 3)
-			   (compilation-speed 2)
-			   (space 1)
-			   (speed 2)
-			   #+nil (sb-ext:inhibit-warnings 2)))
-	(declaim (ftype (function * (values)) emptyvalues))
-	(defun emptyvalues (&rest rest) (declare (ignore rest)) (values))
-	(defstruct foo x y)
-	(defgeneric assertoid ((x t)))
-	(defmethod assertoid ((x t)) "just a placeholder")
-	(defun bar (ht)
-	  (declare (type hash-table ht))
-	  (let ((res
-	         (block blockname
-	           (progn
-	            (prog1
-			(emptyvalues)
-	              (assertoid (hash-table-count ht)))))))
-	    (unless (typep res 'foo)
-	      (locally
-	       (common-lisp-user::bad-result-from-assertive-typed-fun
-	        'bar
-	        res)))))
-  then executing
-	(bar (make-hash-table))
-  causes the failure
-	Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
-	  the function C::%INSTANCE-TYPEP is undefined.
-  %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for
-  some reason -- the (VALUES) return value declaration? -- the optimizer is
-  confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist
-  as a function) instead.
-
-37a:
-  The %INSTANCE-TYPEP problem in bug 37 comes up also when compiling
-  and loading
-	(IN-PACKAGE :CL-USER)
-	(LOCALLY
-	  (DECLARE (OPTIMIZE (SAFETY 3) (SPEED 2) (SPACE 2)))
-	  (DECLAIM (FTYPE (FUNCTION (&REST T) (VALUES)) EMPTYVALUES))
-	  (DEFUN EMPTYVALUES (&REST REST)
-	    (DECLARE (IGNORE REST))
-	    (VALUES))
-	  (DEFSTRUCT DUMMYSTRUCT X Y)
-	  (DEFUN FROB-EMPTYVALUES (X)
-	    (LET ((RES (EMPTYVALUES X X X)))
-	      (UNLESS (TYPEP RES 'DUMMYSTRUCT)
-		'EXPECTED-RETURN-VALUE))))
-	(ASSERT (EQ (FROB-EMPTYVALUES 11) 'EXPECTED-RETURN-VALUE))
-
-
 38:
   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
   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.
+  Or perhaps UPGRADED-ARRAY-ELEMENT-TYPE should just fail when a type
+  isn't defined yet. (What if the definition of
+  SOMETHING-NOT-DEFINED-YET turns out to be SINGLE-FLOAT?) 
 
 41:
   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
@@ -806,6 +686,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   rightward of the correct location.
 
 65:
+  (probably related to bug #70)
   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
   compiling this file
 (in-package "CL-USER")
@@ -875,13 +756,109 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
     (DEFTYPE BAR () 'SIMPLE-VECTOR)
     (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
 
-
 67:
   As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
   and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 
+68: 
+  As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
+  SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
+  notably including all PCL instances. There's a limit to how much
+  SXHASH can do to return unique values for instances, but at least
+  it should probably look at the class name, the way that it does
+  for STRUCTURE-OBJECTs.
+
+69:
+  As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
+  > There remains one issue, that is a bug in SBCL:
+  > According to my interpretation of the spec, the ":" and "@" modifiers
+  > should appear _after_ the comma-seperated arguments.
+  > Well, SBCL (and CMUCL for that matter) accept 
+  > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) "   1"))
+  > where the correct way (IMHO) should be
+  > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) "   1"))
+  Probably SBCL should stop accepting the "~:8D"-style format arguments,
+  or at least issue a warning.
+
+70:
+  (probably related to bug #65)
+  The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
+  forms. E.g.
+    (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
+      (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
+                 (LET ((ITEM (FIRST SEQ)))
+		   (COND ((NULL SEQ)
+			  (VALUES NIL NIL))
+			 ((FUNCALL TEST OBJ ITEM)
+			  (VALUES VAL SEQ))
+			 (T	
+			  (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
+      (FIND-ITEM ITEM SEQUENCE TEST)))
+  from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
+  causes sbcl-0.6.9 to fail with
+    error in function SB-KERNEL:ASSERT-ERROR:
+       The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
+                         (SB-C::LAMBDA-TAIL-SET
+                          (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
+
+71: 
+  (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after 
+  (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
+  the previous SPEED policy. This bug will probably get fixed in
+  0.6.9.x in a general cleanup of optimization policy.
+
+72:
+  (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+74:
+  As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
+  gives a result which isn't COMPLEX. The result type optimizer
+  for COERCE doesn't know this, perhaps because it was written before
+  ANSI threw this curveball: the optimizer thinks that COERCE always
+  returns a result of the specified type. Thus while the interpreted
+  function
+     (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
+  returns the correct result,
+     (TRICKY 3) => NIL
+  the compiled function
+     (COMPILE 'TRICKY)
+  does not:
+     (TRICKY 3) => T
+
+75:
+  As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
+  ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
+  :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
+  WITH-OUTPUT-TO-STRING.
+
+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:
+  The subtle CMU CL bug discussed by Douglas Thomas Crosher on
+  cmucl-imp@cons.org 29 Jan 2001 sounds like something that probably
+  still exists in the corresponding SBCL code.
+
+
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Note: At some point, the pure interpreter (actually a semi-pure