X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fd35adacef5297b408a28a1a72dee8686f308aea;hb=22a6702974b7d6ff4e8f2b3b7b5ff446fc632de0;hp=3512ffe7882a595b51bff675cf3febcb70a812e2;hpb=5369caf4d418065012b96af0d29c74d7851c04ff;p=sbcl.git diff --git a/BUGS b/BUGS index 3512ffe..fd35ada 100644 --- a/BUGS +++ b/BUGS @@ -653,15 +653,6 @@ WORKAROUND: (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not produce invalid code, but type checking is not accurate.) -233: bugs in constraint propagation - b. - (declaim (optimize (speed 2) (safety 3))) - (defun foo (x y) - (if (typep (prog1 x (setq x y)) 'double-float) - (+ x 1d0) - (+ x 2))) - (foo 1d0 5) => segmentation violation - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -909,7 +900,7 @@ WORKAROUND: strongly suspected problems, as of 0.8.3.10: please update this bug instead of creating new ones - localtime() - called for timezone calculations in code/time.lisp + gethostbyname, gethostbyaddr in sb-bsd-sockets 284: Thread safety: special variables There are lots of special variables in SBCL, and I feel sure that at @@ -971,14 +962,6 @@ WORKAROUND: the control word; however, this clobbers any change the user might have made. -296: - (reported by Adam Warner, sbcl-devel 2003-09-23) - - The --load toplevel argument does not perform any sanitization of its - argument. As a result, files with Lisp pathname pattern characters - (#\* or #\?, for instance) or quotation marks can cause the system - to perform arbitrary behaviour. - 297: LOOP with non-constant arithmetic step clauses suffers from overzealous type constraint: code of the form @@ -1945,25 +1928,6 @@ WORKAROUND: #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been disabled on Darwin for now. -375: MISC.555 - (compile nil '(lambda (p1) - (declare (optimize (speed 1) (safety 2) (debug 2) (space 0)) - (type keyword p1)) - (keywordp p1))) - - fails on hairy type check in IR2. - - 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like - transformation could eliminate it). - - 2. From the only call of KEYWORDP the type of its argument is - derived to be KEYWORD. - - 2. Type check for P1 is generated; it uses KEYWORDP to perform the - check, and so references the local function; from the KEYWORDP - argument type new CAST to KEYWORD is generated. The compiler - loops forever. - 377: Memory fault error reporting On those architectures where :C-STACK-IS-CONTROL-STACK is in *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack, @@ -2091,5 +2055,143 @@ WORKAROUND: the right fix is to remove the abstraction violation in the compiler's type deriver. -391: - (fixed in sbcl-0.9.7.1) +393: Wrong error from methodless generic function + (DEFGENERIC FOO (X)) + (FOO 1 2) + gives NO-APPLICABLE-METHOD rather than an argument count error. + +394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug + (found by PFD ansi-tests) + in sbcl-0.9.7.15, (SETF (CLASS-NAME ) 'NIL) causes + (FIND-CLASS NIL) to return a #. + +395: Unicode and streams + One of the remaining problems in SBCL's Unicode support is the lack + of generality in certain streams. + a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT) + to streams made from strings that aren't character strings with + fill-pointers: + (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char))) + (format v "foo") + v) + should return a non-simple base string containing "foo" but + instead errors. + + (reported on sbcl-help by "tichy") + +396: block-compilation bug + (let ((x 1)) + (dotimes (y 10) + (let ((y y)) + (when (funcall (eval #'(lambda (x) (eql x 2))) y) + (defun foo (z) + (incf x (incf y z)))))) + (defun bar (z) + (foo z) + (values x))) + (bar 1) => 11, should be 4. + +397: SLEEP accuracy + The more interrupts arrive the less accurate SLEEP's timing gets. + (time (sb-thread:terminate-thread + (prog1 (sb-thread:make-thread (lambda () + (loop + (princ #\!) + (force-output) + (sb-ext:gc)))) + (sleep 1)))) + +398: GC-unsafe SB-ALIEN string deporting + Translating a Lisp string to an alien string by taking a SAP to it + as done by the :DEPORT-GEN methods for C-STRING and UTF8-STRING + is not safe, since the Lisp string can move. For example the + following code will fail quickly on both cheneygc and pre-0.9.8.19 + GENCGC: + + (setf (bytes-consed-between-gcs) 4096) + (define-alien-routine "strcmp" int (s1 c-string) (s2 c-string)) + + (loop + (let ((string "hello, world")) + (assert (zerop (strcmp string string))))) + + (This will appear to work on post-0.9.8.19 GENCGC, since + the GC no longer zeroes memory immediately after releasing + it after a minor GC. Either enabling the READ_PROTECT_FREE_PAGES + #define in gencgc.c or modifying the example so that a major + GC will occasionally be triggered would unmask the bug.) + + On cheneygc the only solution would seem to be allocating some alien + memory, copying the data over, and arranging that it's freed once we + return. For GENCGC we could instead try to arrange that the string + from which the SAP is taken is always pinned. + + For some more details see comments for (define-alien-type-method + (c-string :deport-gen) ...) in host-c-call.lisp. + +402: "DECLAIM DECLARATION does not inform the PCL code-walker" + reported by Vincent Arkesteijn: + + (declaim (declaration foo)) + (defgeneric bar (x)) + (defmethod bar (x) + (declare (foo x)) + x) + + ==> WARNING: The declaration FOO is not understood by + SB-PCL::SPLIT-DECLARATIONS. + Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*, + SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or + SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*. + (Assuming it is a variable declaration without argument). + +403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE* + In sbcl-0.9.13.34, + (defparameter *c* + (make-condition 'simple-error + :format-control "ow... ~S" + :format-arguments '(#1=(#1#)))) + (setf *print-circle* t *print-level* 4) + (format nil "~@<~A~:@>" *c*) + gives + "ow... (((#)))" + where I (WHN) believe the correct result is "ow... #1=(#1#)", + like the result from (PRINC-TO-STRING *C*). The question of + what the correct result is is complicated by the hairy text in + the Hyperspec "22.3.5.2 Tilde Less-Than-Sign: Logical Block", + Other than the difference in its argument, ~@<...~:> is + exactly the same as ~<...~:> except that circularity detection + is not applied if ~@<...~:> is encountered at top level in a + format string. + But because the odd behavior happens even without the at-sign, + (format nil "~<~A~:@>" (list *c*)) ; => "ow... (((#)))" + and because something seemingly similar can happen even in + PPRINT-LOGICAL-BLOCK invoked directly without FORMAT, + (pprint-logical-block (*standard-output* '(some nonempty list)) + (format *standard-output* "~A" '#1=(#1#))) + (which prints "(((#)))" to *STANDARD-OUTPUT*), I don't think + that the 22.3.5.2 trickiness is fundamental to the problem. + + My guess is that the problem is related to the logic around the MODE + argument to CHECK-FOR-CIRCULARITY, but I haven't reverse-engineered + enough of the intended meaning of the different MODE values to be + confident of this. + +404: nonstandard DWIMness in LOOP with unportably-ordered clauses + In sbcl-0.9.13, the code + (loop with stack = (make-array 2 :fill-pointer 2 :initial-element t) + for length = (length stack) + while (plusp length) + for element = (vector-pop stack) + collect element) + compiles without error or warning and returns (T T). Unfortunately, + it is inconsistent with the ANSI definition of the LOOP macro, + because it mixes up VARIABLE-CLAUSEs with MAIN-CLAUSEs. Furthermore, + SBCL's interpretation of the intended meaning is only one possible, + unportable interpretation of the noncompliant code; in CLISP 2.33.2, + the code compiles with a warning + LOOP: FOR clauses should occur before the loop's main body + and then fails at runtime with + VECTOR-POP: #() has length zero + perhaps because CLISP has shuffled the clauses into an + ANSI-compliant order before proceeding.