X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=2f5f538d20cda7fba9265c26efed77dee6cb5422;hb=ba7659c92f2b7fac7e9532a3db9114c5bdc4ab55;hp=5df3d1b4e304d99ac4f08373e50061de7d01de5b;hpb=dec94b039e8ec90baf21463df839a6181de606f6;p=sbcl.git

diff --git a/BUGS b/BUGS
index 5df3d1b..2f5f538 100644
--- a/BUGS
+++ b/BUGS
@@ -1187,6 +1187,133 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 126:
   (fixed in 0.pre7.41)
 
+127:
+  The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
+  specifies a precedence rule for name collisions between slot accessors of
+  structure classes related by inheritance. As of 0.7.0, SBCL still 
+  doesn't follow it.
+
+128:
+  READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan
+  Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the 
+  list, the Gray streams proposal doesn't mention READ-SEQUENCE and
+  WRITE-SEQUENCE because it predates them, generalizing it to 
+  cover them is an obvious extension, ACL does it, and there's a 
+  patch for for CMU CL which does it too.
+
+129:
+  insufficient syntax checking in MACROLET:
+   (defun foo (x)
+     (macrolet ((defmacro bar (z) `(+ z z)))
+       (bar x)))
+  shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+130:
+  reported by Alexey Dejneka on sbcl-devel 2001-11-03
+   (defun x (x)
+     "Return X if X is a non-negative integer."
+     (let ((step (lambda (%funcall)
+                   (lambda (n)
+                     (cond ((= n 0) 0)
+                           (t (1+ (funcall %funcall (1- n)))))))))
+       (funcall
+        ((lambda (a)
+           (funcall step (lambda (n)
+                           (funcall (funcall a a) n))))
+         (lambda (a)
+           (funcall step (lambda (n)
+                           (funcall (funcall a a) n)))))
+        x)))
+  This function returns its argument. But after removing percents it
+  does not work: "Result of (1- n) is not a function".
+
+131:
+  As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
+  the CL:COMPILE function (which is based on the same %COMPILE 
+  mechanism) get confused by 
+(defun sxhash (x)
+  (labels ((sxhash-number (x)
+	     (etypecase x
+	       (fixnum (sxhash x)) ; through DEFTRANSFORM
+	       (integer (sb!bignum:sxhash-bignum x))
+	       (single-float (sxhash x)) ; through DEFTRANSFORM
+	       (double-float (sxhash x)) ; through DEFTRANSFORM
+	       #!+long-float (long-float (error "stub: no LONG-FLOAT"))
+	       (ratio (let ((result 127810327))
+			(declare (type fixnum result))
+			(mixf result (sxhash-number (numerator x)))
+			(mixf result (sxhash-number (denominator x)))
+			result))
+	       (complex (let ((result 535698211))
+			  (declare (type fixnum result))
+			  (mixf result (sxhash-number (realpart x)))
+			  (mixf result (sxhash-number (imagpart x)))
+			  result))))
+	   (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
+	     (declare (type index depthoid))
+	     (typecase x
+	       (list
+		(if (plusp depthoid)
+		    (mix (sxhash-recurse (car x) (1- depthoid))
+			 (sxhash-recurse (cdr x) (1- depthoid)))
+		    261835505))
+	       (instance
+		(if (typep x 'structure-object)
+		    (logxor 422371266
+			    (sxhash ; through DEFTRANSFORM
+			     (class-name (layout-class (%instance-layout x)))))
+		    309518995))
+	       (symbol (sxhash x)) ; through DEFTRANSFORM
+	       (number (sxhash-number x))
+	       (array
+		(typecase x
+		  (simple-string (sxhash x)) ; through DEFTRANSFORM
+		  (string (%sxhash-substring x))
+		  (bit-vector (let ((result 410823708))
+				(declare (type fixnum result))
+				(dotimes (i (min depthoid (length x)))
+				  (mixf result (aref x i)))
+				result))
+		  (t (logxor 191020317 (sxhash (array-rank x))))))
+	       (character
+		(logxor 72185131
+			(sxhash (char-code x)))) ; through DEFTRANSFORM
+	       (t 42))))
+    (sxhash-recurse x)))
+  complaining "function called with two arguments, but wants exactly
+  one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
+  since IIRC post-fork CMU CL has also had problems with &OPTIONAL
+  arguments in FLET/LABELS: it might be an old Python bug which is 
+  only exercised by the new arrangement of the SBCL compiler.)
+
+132:
+  Trying to compile 
+    (DEFUN FOO () (CATCH 0 (PRINT 1331)))
+  gives an error
+    #<SB-C:TN '0!1> is not valid as the second argument to VOP:
+      SB-C:MAKE-CATCH-BLOCK,
+    since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
+    any of the SCs allowed by the operand restriction:
+     (SB-VM::DESCRIPTOR-REG)
+  The (CATCH 0 ...) construct is bad style (because of unportability
+  of EQ testing of numbers) but it is legal, and shouldn't cause an
+  internal compiler error. (This error occurs in sbcl-0.6.13 and in
+  0.pre7.86.flaky7.14.)
+
+133:
+  Trying to compile something like 
+    (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
+      (code-obj sb!c-call:unsigned-long)
+      (pc-offset sb!c-call:int)
+      (old-inst sb!c-call:unsigned-long))
+  in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
+    cannot use values types here
+  probably because the SB-C-CALL:VOID type gets translated to (VALUES).
+  It should be valid to use VOID for a function return type, so perhaps
+  instead of calling SPECIFIER-TYPE (which excludes all VALUES types
+  automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
+  types manually, allowing the special case (VALUES) but still excluding
+  all more-complex VALUES types.
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER