X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=4b009c11566065249bb7475e8b3deb9b1f886643;hb=aa8c8cd473f1d487fa2c1a7490c78a59b9955bbe;hp=51587c464033b0b7db1e9e0a3388c1ef32f0eeb6;hpb=76874d05d623e0001cfcf23d2c74f78295ba6cee;p=sbcl.git diff --git a/BUGS b/BUGS index 51587c4..4b009c1 100644 --- a/BUGS +++ b/BUGS @@ -84,37 +84,19 @@ WORKAROUND: d: (fixed in 0.8.1.5) -7: - The "compiling top-level form:" output ought to be condensed. - Perhaps any number of such consecutive lines ought to turn into a - single "compiling top-level forms:" line. - -19: - (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep.. -- WHN) - (FORMAT NIL "~,1G" 1.4) => "1. " - (FORMAT NIL "~3,1G" 1.4) => "1. " - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting Process inferior-lisp exited abnormally with code 1 I haven't noticed a repeatable case of this yet. -32: - The printer doesn't report closures very well. This is true in - CMU CL 18b as well: - (PRINT #'CLASS-NAME) - gives - # - It would be nice to make closures have a settable name slot, - and make things like DEFSTRUCT and FLET, which create closures, - set helpful values into this slot. - 33: 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. + Currently INSPECT and DESCRIBE do show the values, but showing the + names of the bindings would be even nicer. + 35: The compiler assumes that any time a function of declared FTYPE doesn't signal an error, its arguments were of the declared type. @@ -156,10 +138,6 @@ WORKAROUND: so they could be supported after all. Very likely SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. -60: - The debugger LIST-LOCATIONS command doesn't work properly. - (How should it work properly?) - 61: Compiling and loading (DEFUN FAIL (X) (THROW 'FAIL-TAG X)) @@ -167,6 +145,12 @@ WORKAROUND: then requesting a BACKTRACE at the debugger prompt gives no information about where in the user program the problem occurred. + (this is apparently mostly fixed on the SPARC, PPC, and x86 architectures: + while giving the backtrace the non-x86 systems complains about "unknown + source location: using block start", but apart from that the + backtrace seems reasonable. On x86 this is masked by bug 353. See + tests/debug.impure.lisp for a test case) + 64: Using the pretty-printer from the command prompt gives funny results, apparently because the pretty-printer doesn't know @@ -190,20 +174,6 @@ WORKAROUND: 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. - - (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to - make the temporary filename less easily guessable) - 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 @@ -228,19 +198,6 @@ WORKAROUND: holding... * is not equivalent to T in many cases, such as (VECTOR *) /= (VECTOR T). -95: - The facility for dumping a running Lisp image to disk gets confused - when run without the PURIFY option, and creates an unnecessarily large - core file (apparently representing memory usage up to the previous - high-water mark). Moreover, when the file is loaded, it confuses the - GC, so that thereafter memory usage can never be reduced below that - level. - - (As of 0.8.7.3 it's likely that the latter half of this bug is fixed. - The interaction between gencgc and the variables used by - save-lisp-and-die is still nonoptimal, though, so no respite from - big core files yet) - 98: In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU CL), out-of-line structure slot setters are horribly inefficient @@ -386,24 +343,6 @@ WORKAROUND: 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) - (defun test-pred (x y) - (eq x y)) - (defun test-case () - (let* ((x *tmp*) - (func (lambda () x))) - (print (eq func func)) - (print (test-pred func func)) - (delete func (list func)))) - Now calling (TEST-CASE) gives output - NIL - NIL - (#) - Evidently Python thinks of the lambda as a code transformation so - much that it forgets that it's also an object. - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -445,6 +384,10 @@ WORKAROUND: conformance problem, since seems hard to construct useful code where it matters.) + [ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests + report that (COMPLEX RATIO) was failing; still failing on types of + the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ] + b. (fixed in 0.8.3.43) 146: @@ -481,20 +424,6 @@ WORKAROUND: This is probably the same bug as 216 -167: - In sbcl-0.7.3.11, compiling the (illegal) code - (in-package :cl-user) - (defmethod prove ((uustk uustk)) - (zap ((frob () nil)) - (frob))) - gives the (not terribly clear) error message - ; caught ERROR: - ; (during macroexpansion of (DEFMETHOD PROVE ...)) - ; can't get template for (FROB NIL NIL) - The problem seems to be that the code walker used by the DEFMETHOD - macro is unhappy with the illegal syntax in the method body, and - is giving an unclear error message. - 173: The compiler sometimes tries to constant-fold expressions before it checks to see whether they can be reached. This can lead to @@ -646,18 +575,6 @@ WORKAROUND: 211: "keywords processing" a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd number of keyword arguments. - e. Compiling - - (flet ((foo (&key y) (list y))) - (list (foo :y 1 :y 2))) - - issues confusing message - - ; in: LAMBDA NIL - ; (FOO :Y 1 :Y 2) - ; - ; caught STYLE-WARNING: - ; The variable #:G15 is defined but never used. 212: "Sequence functions and circular arguments" COERCE, MERGE and CONCATENATE go into an infinite loop when given @@ -736,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)) @@ -803,6 +711,11 @@ WORKAROUND: (UNSIGNED-BYTE 8) will write to the stream one byte at a time, rather than writing the sequence in one go, leading to severe performance degradation. + As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a + problem in practice. (Fully fixing this would require adding a + ansi-stream-n-bout slot and associated methods to write a byte + sequence to ansi-stream, similar to the existing ansi-stream-sout + slot/functions.) 243: "STYLE-WARNING overenthusiasm for unused variables" (observed from clx compilation) @@ -883,26 +796,12 @@ WORKAROUND: b. The same for CSUBTYPEP. 262: "yet another bug in inline expansion of local functions" - Compiler fails on - - (defun foo (x y) - (declare (integer x y)) - (+ (block nil - (flet ((xyz (u) - (declare (integer u)) - (if (> (1+ (the unsigned-byte u)) 0) - (+ 1 u) - (return (+ 38 (cos (/ u 78))))))) - (declare (inline xyz)) - (return-from foo - (* (funcall (eval #'xyz) x) - (if (> x 30) - (funcall (if (> x 5) #'xyz #'identity) - (+ x 13)) - 38))))) - (sin (* x y)))) - - Urgh... It's time to write IR1-copier. + During inline expansion of a local function Python can try to + reference optimized away objects (functions, variables, CTRANs from + tags and blocks), which later may lead to problems. Some of the + cases are worked around by forbidding expansion in such cases, but + the better way would be to reimplement inline expansion by copying + IR1 structures. 266: David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix @@ -922,9 +821,6 @@ WORKAROUND: (list x y))) (funcall (eval #'foo) 1))) -269: - SCALE-FLOAT should accept any integer for its second argument. - 270: In the following function constraint propagator optimizes nothing: @@ -965,16 +861,13 @@ WORKAROUND: (fixed in 0.8.2.51, but a test case would be good) -278: - a. - (defun foo () - (declare (optimize speed)) - (loop for i of-type (integer 0) from 0 by 2 below 10 - collect i)) - - uses generic arithmetic. - - b. (fixed in 0.8.3.6) +276: + b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ. + c. (defvar *faa*) + (defmethod faa ((*faa* double-float)) + (set '*faa* (when (< *faa* 0) (- *faa*))) + (1+ *faa*)) + (faa 1d0) => type error 279: type propagation error -- correctly inferred type goes astray? In sbcl-0.8.3 and sbcl-0.8.1.47, the warning @@ -1001,24 +894,6 @@ WORKAROUND: (see also bug 117) -281: COMPUTE-EFFECTIVE-METHOD error signalling. - (slightly obscured by a non-0 default value for - SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*) - It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors - when it finds a method with invalid qualifiers. However, it - shouldn't signal errors when any such methods are not applicable to - the particular call being evaluated, and certainly it shouldn't when - simply precomputing effective methods that may never be called. - (setf sb-pcl::*max-emf-precompute-methods* 0) - (defgeneric foo (x) - (:method-combination +) - (:method ((x symbol)) 1) - (:method + ((x number)) x)) - (foo 1) -> ERROR, but should simply return 1 - - The issue seems to be that construction of a discriminating function - calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable. - 283: Thread safety: libc functions There are places that we call unsafe-for-threading libc functions that we should find alternatives for, or put locks around. Known or @@ -1087,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 @@ -1126,14 +993,6 @@ WORKAROUND: gives the error failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))" -302: Undefined type messes up DATA-VECTOR-REF expansion. - Compiling this file - (defun dis (s ei x y) - (declare (type (simple-array function (2)) s) (type ei ei)) - (funcall (aref s ei) x y)) - on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled: - full call to SB-KERNEL:DATA-VECTOR-REF - 303: "nonlinear LVARs" (aka MISC.293) (defun buu (x) (multiple-value-call #'list @@ -1151,17 +1010,6 @@ WORKAROUND: The problem is that both EVALs sequentially write to the same LVAR. -305: - (Reported by Dave Roberts.) - Local INLINE/NOTINLINE declaration removes local FTYPE declaration: - - (defun quux (x) - (declare (ftype (function () (integer 0 10)) fee) - (inline fee)) - (1+ (fee))) - - uses generic arithmetic with INLINE and fixnum without. - 306: "Imprecise unions of array types" a.(defun foo (x) (declare (optimize speed) @@ -1178,23 +1026,6 @@ WORKAROUND: collect `(array ,(sb-vm:saetp-specifier x))))) => NIL, T (when it should be T, T) -308: "Characters without names" - (reported by Bruno Haible sbcl-devel "character names are missing" - 2004-04-19) - (graphic-char-p (code-char 255)) - => NIL - (char-name (code-char 255)) - => NIL - - SBCL is unsure of what to do about characters with codes in the - range 128-255. Currently they are treated as non-graphic, but don't - have names, which is not compliant with the standard. Various fixes - are possible, such as - * giving them names such as NON-ASCII-128; - * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular); - * making the characters graphic (makes a certain amount of sense); - * biting the bullet and implementing Unicode (probably quite hard). - 309: "Dubious values for implementation limits" (reported by Bruno Haible sbcl-devel "Incorrect value of multiple-values-limit" 2004-04-19) @@ -1205,13 +1036,6 @@ WORKAROUND: around the same time regarding a call to LIST on sparc with 1000 arguments) and other implementation limit constants. -311: "Tokeniser not thread-safe" - (see also Robert Marlow sbcl-help "Multi threaded read chucking a - spak" 2004-04-19) - The tokenizer's use of *read-buffer* and *read-buffer-length* causes - spurious errors should two threads attempt to tokenise at the same - time. - 314: "LOOP :INITIALLY clauses and scope of initializers" reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP test suite, originally by Thomas F. Burdick. @@ -1229,28 +1053,23 @@ WORKAROUND: Expected: (2 6 15 38) Got: ERROR -317: "FORMAT of floating point numbers" - reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP - test suite. - (format nil "~1F" 10) => "0." ; "10." expected - (format nil "~0F" 10) => "0." ; "10." expected - (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected - it would be nice if whatever fixed this also untangled the two - competing implementations of floating point printing (Steele and - White, and Burger and Dybvig) present in src/code/print.lisp - 318: "stack overflow in compiler warning with redefined class" reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP test suite. - (setq *print-pretty* nil) (defstruct foo a) (setf (find-class 'foo) nil) (defstruct foo slot-1) - gives - ...# + ... + debugger invoked on a TYPE-ERROR in thread 19973: + The value NIL is not of type FUNCTION. + + CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS) + meant to be enough to delete structure classes from the system? 319: "backquote with comma inside array" reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP @@ -1260,20 +1079,6 @@ WORKAROUND: #(1 2 ((SB-IMPL::|,|) + 2 2) 4) which probably isn't intentional. -323: "REPLACE, BIT-BASH and large strings" - The transform for REPLACE on simple-base-strings uses BIT-BASH, which - at present has an upper limit in size. Consequently, in sbcl-0.8.10 - (defun foo () - (declare (optimize speed (safety 1))) - (let ((x (make-string 140000000)) - (y (make-string 140000000))) - (length (replace x y)))) - (foo) - gives - debugger invoked on a TYPE-ERROR in thread 2412: - The value 1120000000 is not of type (MOD 536870911). - (see also "more and better sequence transforms" sbcl-devel 2004-05-10) - 324: "STREAMs and :ELEMENT-TYPE with large bytesize" In theory, (open foo :element-type '(unsigned-byte )) should work for all positive integral . At present, it only works for up @@ -1364,12 +1169,6 @@ WORKAROUND: in the wrapper, and then to update the instance just run through all the old wrappers in order from oldest to newest. -331: "lazy creation of CLOS classes for user-defined conditions" - (defstruct foo) - (defstruct (bar (:include foo))) - (sb-mop:class-direct-subclasses (find-class 'foo)) - returns NIL, rather than a singleton list containing the BAR class. - 332: "fasl stack inconsistency in structure redefinition" (reported by Tim Daly Jr sbcl-devel 2004-05-06) Even though structure redefinition is undefined by the standard, the @@ -1389,42 +1188,6 @@ WORKAROUND: debugger invoked on a SB-INT:BUG in thread 27726: fasl stack not empty when it should be -334: "COMPUTE-SLOTS used to add slots to classes" - (reported by Bruno Haible sbcl-devel 2004-06-01) - a. Adding a local slot does not work: - (use-package "SB-PCL") - (defclass b (a) ()) - (defmethod compute-slots ((class (eql (find-class 'b)))) - (append (call-next-method) - (list (make-instance 'standard-effective-slot-definition - :name 'y - :allocation :instance)))) - (defclass a () ((x :allocation :class))) - ;; A should now have a shared slot, X, and a local slot, Y. - (mapcar #'slot-definition-location (class-slots (find-class 'b))) - yields - There is no applicable method for the generic function - # - when called with arguments - (NIL). - - b. Adding a class slot does not work: - (use-package "SB-PCL") - (defclass b (a) ()) - (defmethod compute-slots ((class (eql (find-class 'b)))) - (append (call-next-method) - (list (make-instance 'standard-effective-slot-definition - :name 'y - :allocation :class)))) - (defclass a () ((x :allocation :class))) - ;; A should now have two shared slots, X and Y. - (mapcar #'slot-definition-location (class-slots (find-class 'b))) - yields - There is no applicable method for the generic function - # - when called with arguments - (NIL). - 336: "slot-definitions must retain the generic functions of accessors" reported by Tony Martinez: (defclass foo () ((bar :reader foo-bar))) @@ -1578,12 +1341,810 @@ WORKAROUND: method is applicable, and yet matches neither of the method group qualifier patterns. -340: SETF of VALUES using too many values - (reported by Kalle Olavi Niemetalo via the Debian bug system, with - bug id #256764) - - (let ((a t) (b t) (c t) (d t)) - (setf (values (values a b) (values c d)) (values 1 2 3 4)) - (list a b c d)) - should return (1 NIL 2 NIL), but under sbcl-0.8.12.x returns - (1 2 3 4) instead. +343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error + Even the simplest possible overriding of + COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation + as "canonical", does not work: + (defclass my-generic-function (standard-generic-function) () + (:metaclass funcallable-standard-class)) + (defmethod compute-discriminating-function ((gf my-generic-function)) + (let ((dfun (call-next-method))) + (lambda (&rest args) + (apply dfun args)))) + (defgeneric foo (x) + (:generic-function-class my-generic-function)) + (defmethod foo (x) (+ x x)) + (foo 5) + signals an error. This error is the same even if the LAMBDA is + replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)). Maybe the + SET-FUNCALLABLE-INSTANCE-FUN scary stuff in + src/code/target-defstruct.lisp is broken? This seems to be broken + in CMUCL 18e, so it's not caused by a recent change. + +344: more (?) ROOM T problems (possibly part of bug 108) + In sbcl-0.8.12.51, and off and on leading up to it, the + SB!VM:MEMORY-USAGE operations in ROOM T caused + unhandled condition (of type SB-INT:BUG): + failed AVER: "(SAP= CURRENT END)" + Several clever people have taken a shot at this without fixing + it; this time around (before sbcl-0.8.13 release) I (WHN) just + commented out the SB!VM:MEMORY-USAGE calls until someone figures + out how to make them work reliably with the rest of the GC. + + (Note: there's at least one dubious thing in room.lisp: see the + comment in VALID-OBJ) + +346: alpha backtrace + In sbcl-0.8.13, all backtraces from errors caused by internal errors + on the alpha seem to have a "bogus stack frame". + +349: PPRINT-INDENT rounding implementation decisions + At present, pprint-indent (and indeed the whole pretty printer) + more-or-less assumes that it's using a monospace font. That's + probably not too silly an assumption, but one piece of information + the current implementation loses is from requests to indent by a + non-integral amount. As of sbcl-0.8.15.9, the system silently + truncates the indentation to an integer at the point of request, but + maybe the non-integral value should be propagated through the + pprinter and only truncated at output? (So that indenting by 1/2 + then 3/2 would indent by two spaces, not one?) + +352: forward-referenced-class trouble + reported by Bruno Haible on sbcl-devel + (defclass c (a) ()) + (setf (class-name (find-class 'a)) 'b) + (defclass a () (x)) + (defclass b () (y)) + (make-instance 'c) + Expected: an instance of c, with a slot named x + Got: debugger invoked on a SIMPLE-ERROR in thread 78906: + While computing the class precedence list of the class named C. + The class named B is a forward referenced class. + The class named B is a direct superclass of the class named C. + +353: debugger suboptimalities on x86 + On x86 backtraces for undefined functions start with a bogus stack + frame, and backtraces for throws to unknown catch tags with a "no + debug information" frame. These are both due to CODE-COMPONENT-FROM-BITS + (used on non-x86 platforms) being a more complete solution then what + is done on x86. + + On x86/linux large portions of tests/debug.impure.lisp have been commented + out as failures. The probable culprit for these problems is in x86-call-context + (things work fine on x86/freebsd). + + More generally, the debugger internals suffer from excessive x86/non-x86 + conditionalization and OAOOMization: refactoring the common parts would + be good. + +354: XEPs in backtraces + Under default compilation policy + (defun test () + (throw :unknown t)) + (test) + Has the XEP for TEST in the backtrace, not the TEST frame itself. + (sparc and x86 at least) + + Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* + is true (instead there appear two TEST frames at least on ppc). The + underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge + the tail-call for the XEP, since Python has by that time proved that + the function can never return; same happens if the function holds an + unconditional call to ERROR. + +355: change-class of generic-function + (reported by Bruno Haible) + The MOP doesn't support change-class on a generic-function. However, SBCL + apparently supports it, since it doesn't give an error or warning when doing + so so. Then, however, it produces wrong results for calls to this generic + function. + ;;; The effective-methods cache: + (progn + (defgeneric testgf35 (x)) + (defmethod testgf35 ((x integer)) + (cons 'integer (if (next-method-p) (call-next-method)))) + (defmethod testgf35 ((x real)) + (cons 'real (if (next-method-p) (call-next-method)))) + (defclass customized5-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defmethod sb-pcl:compute-effective-method ((gf customized5-generic-function) method-combination methods) + `(REVERSE ,(call-next-method))) + (list + (testgf35 3) + (progn + (change-class #'testgf35 'customized5-generic-function) + (testgf35 3)))) + Expected: ((INTEGER REAL) (REAL INTEGER)) + Got: ((INTEGER REAL) (INTEGER REAL)) + ;;; The discriminating-function cache: + (progn + (defgeneric testgf36 (x)) + (defmethod testgf36 ((x integer)) + (cons 'integer (if (next-method-p) (call-next-method)))) + (defmethod testgf36 ((x real)) + (cons 'real (if (next-method-p) (call-next-method)))) + (defclass customized6-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defmethod sb-pcl:compute-discriminating-function ((gf customized6-generic-function)) + (let ((orig-df (call-next-method))) + #'(lambda (&rest arguments) + (reverse (apply orig-df arguments))))) + (list + (testgf36 3) + (progn + (change-class #'testgf36 'customized6-generic-function) + (testgf36 3)))) + Expected: ((INTEGER REAL) (REAL INTEGER)) + Got: ((INTEGER REAL) (INTEGER REAL)) + +356: PCL corruption + (reported by Bruno Haible) + After the "layout depth conflict" error, the CLOS is left in a state where + it's not possible to define new standard-class subclasses any more. + Test case: + (defclass prioritized-dispatcher () + ((dependents :type list :initform nil))) + (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) + (c2 (eql (find-class 'prioritized-dispatcher)))) + t) + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + ;; ERROR, Quit the debugger with ABORT + (defclass typechecking-reader-class (standard-class) + ()) + Expected: # + Got: ERROR "The assertion SB-PCL::WRAPPERS failed." + +357: defstruct inheritance of initforms + (reported by Bruno Haible) + When defstruct and defclass (with :metaclass structure-class) are mixed, + 1. some slot initforms are ignored by the DEFSTRUCT generated constructor + function, and + 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably + OK for initforms that were given in a DEFSTRUCT form, but for those + given in a DEFCLASS form, I think it qualifies as a bug.) + Test case: + (defstruct structure02a + slot1 + (slot2 t) + (slot3 (floor pi))) + (defclass structure02b (structure02a) + ((slot4 :initform -44) + (slot5) + (slot6 :initform t) + (slot7 :initform (floor (* pi pi))) + (slot8 :initform 88)) + (:metaclass structure-class)) + (defstruct (structure02c (:include structure02b (slot8 -88))) + slot9 + (slot10 t) + (slot11 (floor (exp 3)))) + ;; 1. Form: + (let ((a (make-structure02c))) + (list (structure02c-slot4 a) + (structure02c-slot5 a) + (structure02c-slot6 a) + (structure02c-slot7 a))) + Expected: (-44 nil t 9) + Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND.. + SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..) + ;; 2. Form: + (let ((b (make-instance 'structure02c))) + (list (structure02c-slot2 b) + (structure02c-slot3 b) + (structure02c-slot4 b) + (structure02c-slot6 b) + (structure02c-slot7 b) + (structure02c-slot8 b) + (structure02c-slot10 b) + (structure02c-slot11 b))) + Expected: (t 3 -44 t 9 -88 t 20) + Got: (0 0 0 0 0 0 0 0) + +358: :DECLARE argument to ENSURE-GENERIC-FUNCTION + (reported by Bruno Haible) + According to ANSI CL, ensure-generic-function must accept a :DECLARE + keyword argument. In SBCL 0.8.16 it does not. + Test case: + (progn + (ensure-generic-function 'foo113 :declare '((optimize (speed 3)))) + (sb-pcl:generic-function-declarations #'foo113)) + Expected: ((OPTIMIZE (SPEED 3))) + Got: ERROR + Invalid initialization argument: + :DECLARE + in call for class #. + See also: + The ANSI Standard, Section 7.1.2 + + Bruno notes: The MOP specifies that ensure-generic-function accepts :DECLARATIONS. + The easiest way to be compliant to both specs is to accept both (exclusively + or cumulatively). + +359: wrong default value for ensure-generic-function's :generic-function-class argument + (reported by Bruno Haible) + ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says: + "The remaining arguments are the complete set of keyword arguments + received by ENSURE-GENERIC-FUNCTION." + and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS: + ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not + supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION." + This is not the case in SBCL. Test case: + (defclass my-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (setf (fdefinition 'foo1) + (make-instance 'my-generic-function :name 'foo1)) + (ensure-generic-function 'foo1 + :generic-function-class (find-class 'standard-generic-function)) + (class-of #'foo1) + ; => # + (setf (fdefinition 'foo2) + (make-instance 'my-generic-function :name 'foo2)) + (ensure-generic-function 'foo2) + (class-of #'foo2) + Expected: # + Got: # + +360: CALL-METHOD not recognized in method-combination body + (reported by Bruno Haible) + This method combination, which adds 'redo' and 'return' restarts for each + method invocation to standard method combination, gives an error in SBCL. + (defun prompt-for-new-values () + (format *debug-io* "~&New values: ") + (list (read *debug-io*))) + (defun add-method-restarts (form method) + (let ((block (gensym)) + (tag (gensym))) + `(BLOCK ,block + (TAGBODY + ,tag + (RETURN-FROM ,block + (RESTART-CASE ,form + (METHOD-REDO () + :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Try calling ~S again." ,method)) + (GO ,tag)) + (METHOD-RETURN (L) + :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Specify return values for ~S call." ,method)) + :INTERACTIVE (LAMBDA () (PROMPT-FOR-NEW-VALUES)) + (RETURN-FROM ,block (VALUES-LIST L))))))))) + (defun convert-effective-method (efm) + (if (consp efm) + (if (eq (car efm) 'CALL-METHOD) + (let ((method-list (third efm))) + (if (or (typep (first method-list) 'method) (rest method-list)) + ; Reduce the case of multiple methods to a single one. + ; Make the call to the next-method explicit. + (convert-effective-method + `(CALL-METHOD ,(second efm) + ((MAKE-METHOD + (CALL-METHOD ,(first method-list) ,(rest method-list)))))) + ; Now the case of at most one method. + (if (typep (second efm) 'method) + ; Wrap the method call in a RESTART-CASE. + (add-method-restarts + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm))) + (second efm)) + ; Normal recursive processing. + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm)))))) + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm)))) + efm)) + (define-method-combination standard-with-restarts () + ((around (:around)) + (before (:before)) + (primary () :required t) + (after (:after))) + (flet ((call-methods-sequentially (methods) + (mapcar #'(lambda (method) + `(CALL-METHOD ,method)) + methods))) + (let ((form (if (or before after (rest primary)) + `(MULTIPLE-VALUE-PROG1 + (PROGN + ,@(call-methods-sequentially before) + (CALL-METHOD ,(first primary) ,(rest primary))) + ,@(call-methods-sequentially (reverse after))) + `(CALL-METHOD ,(first primary))))) + (when around + (setq form + `(CALL-METHOD ,(first around) + (,@(rest around) (MAKE-METHOD ,form))))) + (convert-effective-method form)))) + (defgeneric testgf16 (x) (:method-combination standard-with-restarts)) + (defclass testclass16a () ()) + (defclass testclass16b (testclass16a) ()) + (defclass testclass16c (testclass16a) ()) + (defclass testclass16d (testclass16b testclass16c) ()) + (defmethod testgf16 ((x testclass16a)) + (list 'a + (not (null (find-restart 'method-redo))) + (not (null (find-restart 'method-return))))) + (defmethod testgf16 ((x testclass16b)) + (cons 'b (call-next-method))) + (defmethod testgf16 ((x testclass16c)) + (cons 'c (call-next-method))) + (defmethod testgf16 ((x testclass16d)) + (cons 'd (call-next-method))) + (testgf16 (make-instance 'testclass16d)) + + Expected: (D B C A T T) + Got: ERROR CALL-METHOD outside of a effective method form + + This is a bug because ANSI CL HyperSpec/Body/locmac_call-m__make-method + says + "The macro call-method invokes the specified method, supplying it with + arguments and with definitions for call-next-method and for next-method-p. + If the invocation of call-method is lexically inside of a make-method, + the arguments are those that were supplied to that method. Otherwise + the arguments are those that were supplied to the generic function." + and the example uses nothing more than these two cases (as you can see by + doing (trace convert-effective-method)). + +361: initialize-instance of standard-reader-method ignores :function argument + (reported by Bruno Haible) + Pass a custom :function argument to initialize-instance of a + standard-reader-method instance, but it has no effect. + ;; Check that it's possible to define reader methods that do typechecking. + (progn + (defclass typechecking-reader-method (sb-pcl:standard-reader-method) + ()) + (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs + &key slot-definition) + (let ((name (sb-pcl:slot-definition-name slot-definition)) + (type (sb-pcl:slot-definition-type slot-definition))) + (apply #'call-next-method method + :function #'(lambda (args next-methods) + (declare (ignore next-methods)) + (apply #'(lambda (instance) + (let ((value (slot-value instance name))) + (unless (typep value type) + (error "Slot ~S of ~S is not of type ~S: ~S" + name instance type value)) + value)) + args)) + initargs))) + (defclass typechecking-reader-class (standard-class) + ()) + (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class)) + t) + (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args) + (find-class 'typechecking-reader-method)) + (defclass testclass25 () + ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair)) + (:metaclass typechecking-reader-class)) + (macrolet ((succeeds (form) + `(not (nth-value 1 (ignore-errors ,form))))) + (let ((p (list 'abc 'def)) + (x (make-instance 'testclass25))) + (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17))) + (succeeds (setf (testclass25-pair x) p)) + (succeeds (setf (second p) 456)) + (succeeds (testclass25-pair x)) + (succeeds (slot-value x 'pair)))))) + Expected: (t t t nil t) + Got: (t t t t t) + + (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair))) + shows that the method was created with a FAST-FUNCTION slot but with a + FUNCTION slot of NIL. + +362: missing error when a slot-definition is created without a name + (reported by Bruno Haible) + The MOP says about slot-definition initialization: + "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument + is not a symbol which can be used as a variable name. An ERROR is SIGNALled + if this argument is not supplied." + Test case: + (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)) + Expected: ERROR + Got: # + +363: missing error when a slot-definition is created with a wrong documentation object + (reported by Bruno Haible) + The MOP says about slot-definition initialization: + "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled + if it is not. This argument default to NIL during initialization." + Test case: + (make-instance (find-class 'sb-pcl:standard-direct-slot-definition) + :name 'foo + :documentation 'not-a-string) + Expected: ERROR + Got: # + +364: does not support class objects as specializer names + (reported by Bruno Haible) + According to ANSI CL 7.6.2, class objects are valid specializer names, + and "Parameter specializer names are used in macros intended as the + user-level interface (defmethod)". DEFMETHOD's syntax section doesn't + mention this possibility in the BNF for parameter-specializer-name; + however, this appears to be an editorial omission, since the CLHS + mentions issue CLASS-OBJECT-SPECIALIZER:AFFIRM as being approved + by X3J13. SBCL doesn't support it: + (defclass foo () ()) + (defmethod goo ((x #.(find-class 'foo))) x) + Expected: #)> + Got: ERROR "# is not a legal class name." + +365: mixin on generic-function subclass + (reported by Bruno Haible) + a mixin class + (defclass prioritized-dispatcher () + ((dependents :type list :initform nil))) + on a generic-function subclass: + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + SBCL gives an error on this, telling to define a method on SB-MOP:VALIDATE-SUPERCLASS. If done, + (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) + (c2 (eql (find-class 'prioritized-dispatcher)))) + t) + then, however, + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + => debugger invoked on a SIMPLE-ERROR in thread 6687: + layout depth conflict: #(# ...) + + Further discussion on this: http://thread.gmane.org/gmane.lisp.steel-bank.general/491 + +366: cannot define two generic functions with user-defined class + (reported by Bruno Haible) + it is possible to define one generic function class and an instance + of it. But attempting to do the same thing again, in the same session, + leads to a "Control stack exhausted" error. Test case: + (defclass my-generic-function-1 (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defgeneric testgf-1 (x) (:generic-function-class my-generic-function-1) + (:method ((x integer)) (cons 'integer nil))) + (defclass my-generic-function-2 (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defgeneric testgf-2 (x) (:generic-function-class my-generic-function-2) + (:method ((x integer)) (cons 'integer nil))) + => SB-KERNEL::CONTROL-STACK-EXHAUSTED + +367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime + This test program + (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) + (defstruct e367) + (defstruct i367) + (defstruct g367 + (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null))) + (defstruct s367 + (g367 (error "missing :G367") :type g367 :read-only t)) + ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367)) + ;;; gives an internal error at compile time: + ;;; The value # is not of + ;;; type SB-KERNEL:VALUES-TYPE. + (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367)) + (declaim (ftype (function ((vector e367)) (values)) h367)) + (defun frob (v w) + (let ((x (g367-i367s (make-g367)))) + (let* ((y (or (r367 x w) + (h367 x))) + (z (s367-g367 y))) + (format t "~&Y=~S Z=~S~%" y z) + (g367-i367s z)))) + (defun r367 (x y) (declare (ignore x y)) nil) + (defun h367 (x) (declare (ignore x)) (values)) + ;;; In sbcl-0.8.18, executing this form causes an low-level error + ;;; segmentation violation at #X9B0E1F4 + ;;; (instead of the TYPE-ERROR that one might like). + (frob 0 (make-e367)) + can be made to cause two different problems, as noted in the comments: + bug 367a: Compile and load the file. No TYPE-ERROR is signalled at + run time (in the (S367-G367 Y) form of FROB, when Y is NIL + instead of an instance of S367). Instead (on x86/Linux at least) + we end up with a segfault. + bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile + the file. The compiler fails with TYPE-ERROR at compile time. + +368: miscompiled OR (perhaps related to bug 367) + Trying to relax type declarations to find a workaround for bug 367, + it turns out that even when the return type isn't declared (or + declared to be T, anyway) the system remains confused about type + inference in code similar to that for bug 367: + (in-package :cl-user) + (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) + (defstruct e368) + (defstruct i368) + (defstruct g368 + (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null))) + (defstruct s368 + (g368 (error "missing :G368") :type g368 :read-only t)) + (declaim (ftype (function (fixnum (vector i368) e368) t) r368)) + (declaim (ftype (function (fixnum (vector e368)) t) h368)) + (defparameter *h368-was-called-p* nil) + (defun nsu (vertices e368) + (let ((i368s (g368-i368s (make-g368)))) + (let ((fuis (r368 0 i368s e368))) + (format t "~&FUIS=~S~%" fuis) + (or fuis (h368 0 i368s))))) + (defun r368 (w x y) + (declare (ignore w x y)) + nil) + (defun h368 (w x) + (declare (ignore w x)) + (setf *h368-was-called-p* t) + (make-s368 :g368 (make-g368))) + (trace r368 h368) + (format t "~&calling NSU~%") + (let ((nsu (nsu #() (make-e368)))) + (format t "~&NSU returned ~S~%" nsu) + (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*) + (assert (s368-p nsu)) + (assert *h368-was-called-p*)) + In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows + that no call to H368 is compiled. + +369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION + In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ + does not hold for VALUES-TYPE-INTERSECTION, even for types which + can be intersected exactly, so that ASSERTs fail in this test case: + (in-package :cl-user) + (let ((types (mapcar #'sb-c::values-specifier-type + '((values (vector package) &optional) + (values (vector package) &rest t) + (values (vector hash-table) &rest t) + (values (vector hash-table) &optional) + (values t &optional) + (values t &rest t) + (values nil &optional) + (values nil &rest t) + (values sequence &optional) + (values sequence &rest t) + (values list &optional) + (values list &rest t))))) + (dolist (x types) + (dolist (y types) + (let ((i (sb-c::values-type-intersection x y))) + (assert (sb-c::type= i (sb-c::values-type-intersection i x))) + (assert (sb-c::type= i (sb-c::values-type-intersection i y))))))) + +370: reader misbehaviour on large-exponent floats + (read-from-string "1.0s1000000000000000000000000000000000000000") + causes the reader to attempt to create a very large bignum (which it + will then attempt to coerce to a rational). While this isn't + completely wrong, it is probably not ideal -- checking the floating + point control word state and then returning the relevant float + (most-positive-short-float or short-float-infinity) or signalling an + error immediately would seem to make more sense. + +372: floating-point overflow not signalled on ppc/darwin + The following assertions in float.pure.lisp fail on ppc/darwin + (Mac OS X version 10.3.7): + (assert (raises-error? (scale-float 1.0 most-positive-fixnum) + floating-point-overflow)) + (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum)) + floating-point-overflow))) + as the SCALE-FLOAT just returns + #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been + disabled on Darwin for now. + +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, + so we cannot handle the signal directly (as in interrupt_handle_now()) + in the case when the signal comes from some external agent (the user + using kill(1), or a fault in some foreign code, for instance). As + of sbcl-0.8.20.20, this is fixed by calling + arrange_return_to_lisp_function() to a new error-signalling + function, but as a result the error reporting is poor: we cannot + even tell the user at which address the fault occurred. We should + arrange such that arguments can be passed to the function called from + arrange_return_to_lisp_function(), but this looked hard to do in + general without suffering from memory leaks. + +379: TRACE :ENCAPSULATE NIL broken on ppc/darwin + See commented-out test-case in debug.impure.lisp. + +380: Accessor redefinition fails because of old accessor name + When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to + find the generic function named by the old accessor name using + ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in + the GF. If the old name does not name a function, or if the old name + does not name a generic function, no attempt to find the GF or remove + any methods is made. + + However, if an unrelated GF with an incompatible lambda list exists, + the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD + tries to find and remove a method with an incompatible lambda list + from the unrelated generic function. + +381: incautious calls to EQUAL in fasl dumping + Compiling + (frob #(#1=(a #1#))) + (frob #(#1=(b #1#))) + (frob #(#1=(a #1#))) + in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression + is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL) + to detect sharing, in which case fixing it might require either + getting less ambitious about detecting shared list structure, or + implementing the moral equivalent of EQUAL hash tables in a + cycle-tolerant way. + +382: externalization unexpectedly changes array simplicity + COMPILE-FILE and LOAD + (defun foo () + (let ((x #.(make-array 4 :fill-pointer 0))) + (values (eval `(typep ',x 'simple-array)) + (typep x 'simple-array)))) + then (FOO) => T, NIL. + + Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors + and all array dimension functions. + +383: ASH'ing non-constant zeros + Compiling + (lambda (b) + (declare (type (integer -2 14) b)) + (declare (ignorable b)) + (ash (imagpart b) 57)) + on PPC (and other platforms, presumably) gives an error during the + emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to + stuff a too-large constant into the immediate field of a PPC + instruction. Either the VOP should be fixed or the compiler should be + taught how to transform this case away, paying particular attention + to side-effects that might occur in the arguments to ASH. + +384: Compiler runaway on very large character types + + (compile nil '(lambda (x) + (declare (type (member #\a 1) x)) + (the (member 1 nil) x))) + + The types apparently normalize into a very large type, and the compiler + gets lost in REMOVE-DUPLICATES. Perhaps the latter should use + a better algorithm (one based on hash tables, say) on very long lists + when :TEST has its default value? + + A simpler example: + + (compile nil '(lambda (x) (the (not (eql #\a)) x))) + + (partially fixed in 0.9.3.1, but a better representation for these + types is needed.) + +385: + (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0"); + (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0"). + +386: SunOS/x86 stack exhaustion handling broken + According to , the + stack exhaustion checking (implemented with a write-protected guard + page) does not work on SunOS/x86. + +387: + 12:10 < jsnell> the package-lock test is basically due to a change in the test + behaviour when you install a handler for error around it. I + thought I'd disabled the test for now, but apparently that was + my imagination + 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff + 12:19 < Xophe> it's the same problem as we had with compiler-error conditions + 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of + ERROR, where it probably shouldn't be + +388: + (found by Dmitry Bogomolov) + + (defclass foo () ((x :type (unsigned-byte 8)))) + (defclass bar () ((x :type symbol))) + (defclass baz (foo bar) ()) + + causes error + + SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument + (UNSIGNED-BYTE 8). + +389: + (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and + others) + + ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT + specifying whether they're SINGLE or DOUBLE. This is true for types + computed by the type system itself, but the compiler type derivation + short-circuits this and constructs non-canonical types. A temporary + fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but + the right fix is to remove the abstraction violation in the + compiler's type deriver. + +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. + +401: "optimizer runaway on bad constant type specifiers in TYPEP" + In 0.9.12.3 (and probably many earlier versions), COMPILE-FILE on + (defun ouch401 () + (etypecase (signum (- x y)) + ((-1 nil)) + ((0 1) (oops "shouldn't happen")))) + or just + (defun foo401 (x) + (typep x '(-1 nil))) + spins emitting what seems to be an endless series of compiler + warnings like + ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP + ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP + ; --> TYPEP + ; ==> + ; (TYPEP SB-C::OBJECT '(-1 NIL)) + ; + ; caught WARNING: + ; illegal type specifier for TYPEP: (-1 NIL)