X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=a2953f909fa75984db793c7a081682d59cf7a685;hb=d2cbbce99d82ad691626e6371085e5b20e7cb6c2;hp=afe5c22348fc08b5ea8b79874fcfa7ee40fda036;hpb=e62a03c99097db9454d66f32b5edbd6af874a539;p=sbcl.git diff --git a/BUGS b/BUGS index afe5c22..a2953f9 100644 --- a/BUGS +++ b/BUGS @@ -184,7 +184,6 @@ WORKAROUND: (FOO 1.5) will cause the INTEGERP case to be selected, giving bogus output a la exactly 2.5 - (or (FOO 1000.5), "exactly 1001.5") This violates the "declarations are assertions" principle. According to the ANSI spec, in the section "System Class FUNCTION", this is a case of "lying to the compiler", but the lying is done @@ -254,23 +253,8 @@ WORKAROUND: 46: type safety errors reported by Peter Van Eynde July 25, 2000: - a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4))) - => #(A B C) - In general lengths of array type specifications aren't - checked by COERCE, so it fails when the spec is - (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever. - b: CONCATENATE has the same problem of not checking the length - of specified output array types. MAKE-SEQUENCE and MAP and - MERGE also have the same problem. c: (COERCE 'AND 'FUNCTION) returns something related to (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) - should signal TYPE-ERROR. - i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can - be used for input and output as needed. It should fail with - TYPE-ERROR when handed e.g. the results of - MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in - the inappropriate positions, but doesn't. k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is not a binary input stream, but instead cheerfully reads from character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). @@ -280,11 +264,6 @@ WORKAROUND: d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead causes a COMPILER-ERROR. -48: - SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something - it binds is declared SPECIAL inside. - 51: miscellaneous errors reported by Peter Van Eynde July 25, 2000: a: (PROGN @@ -297,9 +276,6 @@ WORKAROUND: (DEFGENERIC FOO03 (X)) (ADD-METHOD (FUNCTION FOO03) M))) should give an error, but SBCL allows it. - b: READ should probably return READER-ERROR, not the bare - arithmetic error, when input a la "1/0" or "1e1000" causes - an arithmetic error. 52: It has been reported (e.g. by Peter Van Eynde) that there are @@ -374,26 +350,6 @@ WORKAROUND: the new output block should start indented 2 or more characters rightward of the correct location. -66: - ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be - a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: - (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3) - This also leads to funny behavior when derived type specifiers - are used, as originally reported by Milan Zamazal for CMU CL (on the - Debian bugs mailing list (?) 2000-02-27), then reported by Martin - Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net): - (DEFTYPE FOO () 'SIMPLE-ARRAY) - (CONCATENATE 'FOO #(1 2) '(3)) - => # is a bad type specifier for - sequence functions. - The derived type specifier FOO should act the same way as the - built-in type SIMPLE-ARRAY here, but it doesn't. That problem - doesn't seem to exist for sequence types: - (DEFTYPE BAR () 'SIMPLE-VECTOR) - (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) - See also bug #46a./b., and discussion and patch sbcl-devel and - cmucl-imp 2002-07 - 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) @@ -461,6 +417,10 @@ WORKAROUND: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) + In fact, the type system is likely to depend on this inequality not + holding... * is not equivalent to T in many cases, such as + (VECTOR *) /= (VECTOR T). + 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -558,24 +518,6 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -110: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - ;;; The compiler is flushing the argument type test, and the default - ;;; case in the cond, so that calling with say a fixnum 0 causes a - ;;; SIGBUS. - (declaim (optimize (safety 2) (speed 3))) - (defun tst (x) - (declare (type (or string stream) x)) - (cond ((typep x 'string) 'string) - ((typep x 'stream) 'stream) - (t - 'none))) - The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM - (not the SIGBUS reported in the comment) but that's broken too; - type declarations are supposed to be treated as assertions unless - SAFETY 0, so we should be getting a TYPE-ERROR. - 115: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -665,11 +607,11 @@ WORKAROUND: 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available - in the bodies of the macroexpander functions. In particular, it - allows the function bodies (which run at compile time) to try to + in the bodies of the macroexpander functions. In particular, it + allows the function bodies (which run at compile time) to try to access lexical variables (which are only defined at runtime). It doesn't even issue a warning, which is bad. - + The SBCL behavior arguably conforms to the ANSI spec (since the spec says that the behavior is undefined, ergo anything conforms). However, it would be better to issue a compile-time error. @@ -685,7 +627,7 @@ WORKAROUND: the local macro definitions in a MACROLET, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that - lexical environment. + lexical environment. Then it seems to contradict itself by giving the example (defun foo (x flag) (macrolet ((fudge (z) @@ -702,6 +644,12 @@ WORKAROUND: but actual specification quoted above says that the actual behavior is undefined. + (Since 0.7.8.23 macroexpanders are defined in a restricted version + of the lexical environment, containing no lexical variables and + functions, which seems to conform to ANSI and CLtL2, but signalling + a STYLE-WARNING for references to variables similar to locals might + be a good thing.) + 125: (as reported by Gabe Garza on cmucl-help 2001-09-21) (defvar *tmp* 3) @@ -726,81 +674,15 @@ WORKAROUND: structure classes related by inheritance. As of 0.7.0, SBCL still doesn't follow it. -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). - -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.) - 135: Ideally, uninterning a symbol would allow it, and its associated - FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, + FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, at least as of sbcl-0.7.0, this isn't the case. Information about FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp essentially in ordinary (non-weak) hash tables keyed by symbols. Thus, once a system has an entry in this system, it tends to live forever, even when it is uninterned and all other references to it - are lost. + are lost. 136: (reported by Arnaud Rouanet on cmucl-imp 2001-12-18) @@ -830,7 +712,7 @@ WORKAROUND: T * (defclass b () ()) # - + ;;; And now... * (subtypep 'b 'a) T @@ -838,7 +720,7 @@ WORKAROUND: This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper class upon redefinition. Unfortunately, doing so causes bug #176 to - appear. Pending further investication, one or other of these bugs + appear. Pending further investigation, one or other of these bugs might be present at any given time. 141: @@ -849,12 +731,6 @@ WORKAROUND: * (lisp-implementation-version) "0.pre7.129" -142: - (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16) - %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte - of the naturalized string. We could probably port the patches - from the cmucl-imp mailing list. - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -936,27 +812,14 @@ WORKAROUND: debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type SB-C::NODE. The location of this failure has moved around as various related - issues were cleaned up. As of sbcl-0.7.1.9, it occurs in + issues were cleaned up. As of sbcl-0.7.1.9, it occurs in NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE. -153: - (essentially the same problem as a CMU CL bug reported by Martin - Cracauer on cmucl-imp 2002-02-19) - There is a hole in structure slot type checking. Compiling and LOADing - (declaim (optimize safety)) - (defstruct foo - (bla 0 :type fixnum)) - (defun f () - (let ((foo (make-foo))) - (setf (foo-bla foo) '(1 . 1)) - (format t "Is ~a of type ~a a cons? => ~a~%" - (foo-bla foo) - (type-of (foo-bla foo)) - (consp (foo-bla foo))))) - (f) - should signal an error, but in sbcl-0.7.1.21 instead gives the output - Is (1 . 1) of type CONS a cons? => NIL - without signalling an error. + (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline + expand KID-FROB into %ZEEP. Having partially done it, it sees a call + of KIDIFY1, which already does not exist. So it gives up on + expansion, leaving garbage consisting of infinished blocks of the + partially converted function.) 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and @@ -1022,18 +885,6 @@ WORKAROUND: macro is unhappy with the illegal syntax in the method body, and is giving an unclear error message. -168: - (reported by Dan Barlow on sbcl-devel 2002-05-10) - In sbcl-0.7.3.12, doing - (defstruct foo bar baz) - (compile nil (lambda (x) (or x (foo-baz x)))) - gives an error - debugger invoked on condition of type SB-INT:BUG: - full call to SB-KERNEL:%INSTANCE-REF - This is probably a bug in SBCL itself. [...] - Since this is a reasonable user error, it shouldn't be reported as - an SBCL bug. - 172: sbcl's treatment of at least macro lambda lists is too permissive; e.g., in sbcl-0.7.3.7: @@ -1094,24 +945,14 @@ WORKAROUND: In sbcl-0.7.4.24, compiling (defun bug178 (x) (funcall (the function (the standard-object x)))) - gives + gives failed AVER: "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" This variant compiles OK, though: (defun bug178alternative (x) (funcall (the nil x))) -181: "bad type specifier drops compiler into debugger" - Compiling - (in-package :cl-user) - (defun bar (x) - (declare (type 0 x)) - (cons x x)) - signals - bad thing to be a type specifier: 0 - which seems fine, but also enters the debugger (instead of having - the compiler handle the error, convert it into a COMPILER-ERROR, and - continue compiling) which seems wrong. + (since 0.7.8.9 it does not signal an error; see also bug 199) 183: "IEEE floating point issues" Even where floating point handling is being dealt with relatively @@ -1281,6 +1122,8 @@ WORKAROUND: (print j)))) (trust-assertion 6) ; prints nothing unless DECLARE is commented out + (see bug 203) + 193: "unhelpful CLOS error reporting when the primary method is missing" In sbcl-0.7.7, when (defmethod foo :before ((x t)) (print x)) @@ -1356,11 +1199,81 @@ WORKAROUND: APD further reports that this bug is not present in CMUCL. -200: "TRANSLATE-LOGICAL-PATHNAME fails on physical pathname namestrings" - Reported by Kevin Rosenburg on #lisp IRC 2002-09-16 - (TRANSLATE-LOGICAL-PATHNAME "/") - should simply return #P"/", but signals an error in sbcl-0.7.7.28 + (this case was fixed in 0.7.8.9; see also bug 178) +201: "Incautious type inference from compound CONS types" + (reported by APD sbcl-devel 2002-09-17) + (DEFUN FOO (X) + (LET ((Y (CAR (THE (CONS INTEGER *) X)))) + (SETF (CAR X) NIL) + (FORMAT NIL "~S IS ~S, Y = ~S" + (CAR X) + (TYPECASE (CAR X) + (INTEGER 'INTEGER) + (T '(NOT INTEGER))) + Y))) + + (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" + +203: + Compiler does not check THEs on unused values, e.g. in + + (progn (the real (list 1)) t) + + This situation may appear during optimizing away degenerate cases of + certain functions: see bugs 54, 192b. + +205: "environment issues in cross compiler" + (These bugs have no impact on user code, but should be fixed or + documented.) + a. Macroexpanders introduced with MACROLET are defined in the null + lexical environment. + b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in + the null lexical environment. + +206: ":SB-FLUID feature broken" + (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) + Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks + the build. + +207: "poorly distributed SXHASH results for compound data" + SBCL's SXHASH could probably try a little harder. ANSI: "the + intent is that an implementation should make a good-faith + effort to produce hash-codes that are well distributed + within the range of non-negative fixnums". But + (let ((hits (make-hash-table))) + (dotimes (i 16) + (dotimes (j 16) + (let* ((ij (cons i j)) + (newlist (push ij (gethash (sxhash ij) hits)))) + (when (cdr newlist) + (format t "~&collision: ~S~%" newlist)))))) + reports lots of collisions in sbcl-0.7.8. A stronger MIX function + would be an obvious way of fix. Maybe it would be acceptably efficient + to redo MIX using a lookup into a 256-entry s-box containing + 29-bit pseudorandom numbers? + +208: "package confusion in PCL handling of structure slot handlers" + In sbcl-0.7.8 compiling and loading + (in-package :cl) + (defstruct foo (slot (error "missing")) :type list :read-only t) + (defmethod print-object ((foo foo) stream) (print nil stream)) + causes CERROR "attempting to modify a symbol in the COMMON-LISP + package: FOO-SLOT". (This is fairly bad code, but still it's hard + to see that it should cause symbols to be interned in the CL package.) + +209: "DOCUMENTATION generic function has wrong argument precedence order" + The method from + (DEFMETHOD DOCUMENTATION ((X (EQL '+)) Y) "WRONG!") + should not be executed in the call + (DOCUMENTATION '+ 'FUNCTION), + as the DOCUMENTATION generic function has a different argument + precedence order (see its entry in the CLHS). However, despite a + correct generic function definition in the PCL source code, SBCL + returns "WRONG!" for the call. + +210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors" + (fixed in sbcl-0.7.8.35) DEFUNCT CATEGORIES OF BUGS IR1-#: