X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=df217516b1ee2c0d1fa241b97c540f2d8eb9a805;hp=2304eb1ac78258e74b938a2b9b51098122ef8841;hpb=7c1298a73f97b8c71474d8aa4a7c8f863fe0718d;p=sbcl.git diff --git a/BUGS b/BUGS index 2304eb1..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,1465 +1,17 @@ -REPORTING BUGS +SBCL uses Launchpad to track bugs. The bug database is available at: -Bugs can be reported on the help mailing list - sbcl-help@lists.sourceforge.net -or on the development mailing list - sbcl-devel@lists.sourceforge.net + https://bugs.launchpad.net/sbcl -Please include enough information in a bug report that someone reading -it can reproduce the problem, i.e. don't write - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug? -but instead - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when - I compile and load the file - (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y) - (LET ((*PRINT-LENGTH* 4)) - (PRINT X Y))))) - X Y) - then at the command line type - (MAKE-FOO) - the program loops endlessly instead of printing the object. +Reporting bugs there requires registering at Launchpad. However, bugs +can also be reported on the mailing list sbcl-bugs, which is +moderated but does _not_ require subscribing. Simply send email to + sbcl-bugs@lists.sourceforge.net -NOTES: +and the bug will be checked and added to Launchpad by SBCL maintainers. -There is also some information on bugs in the manual page and -in the TODO file. Eventually more such information may move here. +Historical note: before Launchpad was adopted this file contained a +list of currently open bugs. If you run into an SBCL bug number in the +range 1-431 inclusive, it refers to that list. -The gaps in the number sequence belong to old bug descriptions which -have gone away (typically because they were fixed, but sometimes for -other reasons, e.g. because they were moved elsewhere). - - -2: - DEFSTRUCT almost certainly should overwrite the old LAYOUT information - instead of just punting when a contradictory structure definition - is loaded. As it is, if you redefine DEFSTRUCTs in a way which - changes their layout, you probably have to rebuild your entire - program, even if you know or guess enough about the internals of - SBCL to wager that this (undefined in ANSI) operation would be safe. - -3: "type checking of structure slots" - a: - ANSI specifies that a type mismatch in a structure slot - initialization value should not cause a warning. -WORKAROUND: - This one might not be fixed for a while because while we're big - believers in ANSI compatibility and all, (1) there's no obvious - simple way to do it (short of disabling all warnings for type - mismatches everywhere), and (2) there's a good portable - workaround, and (3) by their own reasoning, it looks as though - ANSI may have gotten it wrong. ANSI justifies this specification - by saying - The restriction against issuing a warning for type mismatches - between a slot-initform and the corresponding slot's :TYPE - option is necessary because a slot-initform must be specified - in order to specify slot options; in some cases, no suitable - default may exist. - However, in SBCL (as in CMU CL or, for that matter, any compiler - which really understands Common Lisp types) a suitable default - does exist, in all cases, because the compiler understands the - concept of functions which never return (i.e. has return type NIL). - Thus, as a portable workaround, you can use a call to some - known-never-to-return function as the default. E.g. - (DEFSTRUCT FOO - (BAR (ERROR "missing :BAR argument") - :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF)) - or - (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG)) - (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing - (ERROR "missing required argument")) - (DEFSTRUCT FOO - (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) - (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) - (N-REFS-SO-FAR 0 :TYPE (INTEGER 0))) - Such code should compile without complaint and work correctly either - on SBCL or on any other completely compliant Common Lisp system. - - b: &AUX argument in a boa-constructor without a default value means - "do not initilize this slot" and does not cause type error. But - an error may be signalled at read time and it would be good if - SBCL did it. - - 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. - -11: - It would be nice if the - caught ERROR: - (during macroexpansion) - said what macroexpansion was at fault, e.g. - caught ERROR: - (during macroexpansion of IN-PACKAGE, - during macroexpansion of DEFFOO) - -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. - -35: - The compiler assumes that any time a function of declared FTYPE - doesn't signal an error, its arguments were of the declared type. - E.g. compiling and loading - (DECLAIM (OPTIMIZE (SAFETY 3))) - (DEFUN FACTORIAL (X) (GAMMA (1+ X))) - (DEFUN GAMMA (X) X) - (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL)) - (DEFUN FOO (X) - (COND ((> (FACTORIAL X) 1.0E6) - (FORMAT T "too big~%")) - ((INTEGERP X) - (FORMAT T "exactly ~S~%" (FACTORIAL X))) - (T - (FORMAT T "approximately ~S~%" (FACTORIAL X))))) - then executing - (FOO 1.5) - will cause the INTEGERP case to be selected, giving bogus output a la - exactly 2.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 - by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments, - not by the unexpectedly general definition of FACTORIAL. In any case, - "declarations are assertions" means that lying to the compiler should - cause an error to be signalled, and should not cause a bogus - result to be returned. Thus, the compiler should not assume - that arbitrary functions check their argument types. (It might - make sense to add another flag (CHECKED?) to DEFKNOWN to - identify functions which *do* check their argument types.) - (Also, verify that the compiler handles declared function - return types as assertions.) - -42: - The definitions of SIGCONTEXT-FLOAT-REGISTER and - %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not - supported on FreeBSD because the floating point state is not saved, - but at least as of FreeBSD 4.0, the floating point state *is* saved, - so they could be supported after all. Very likely - SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. - -45: - a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - c: Many expressions generate floating infinity on x86/Linux: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. sbcl-0.7.0.5 - on x86/Linux generates the infinities instead. That might or - might not be conforming behavior, but it's also inconsistent, - which is almost certainly wrong. (Inconsistency: (/ 1 0.0) - should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0) - generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0) - signals an error. - d: (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) - don't give the right behavior. - -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)) - (FAIL 12) - then requesting a BACKTRACE at the debugger prompt gives no information - about where in the user program the problem occurred. - -64: - Using the pretty-printer from the command prompt gives funny - results, apparently because the pretty-printer doesn't know - about user's command input, including the user's carriage return - that the user, and therefore the pretty-printer thinks that - the new output block should start indented 2 or more characters - rightward of the correct location. - -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. - -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. - - (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 - the mean of the distribution can be systematically O(0.1%) wrong. - Just increasing R-I-E-B is probably not a good solution, since - it would decrease efficiency more than is probably necessary. Perhaps - using some sort of accept/reject method would be better. - -85: - Internally the compiler sometimes evaluates - (sb-kernel:type/= (specifier-type '*) (specifier-type t)) - (I stumbled across this when I added an - (assert (not (eq type1 *wild-type*))) - in the NAMED :SIMPLE-= type method.) '* isn't really a type, and - in a type context should probably be translated to T, and so it's - probably wrong to ask whether it's equal to the T type and then (using - the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL. - (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). - -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 - whenever the type of the slot is declared, because out-of-line - structure slot setters are implemented as closures to save space, - so the compiler doesn't compile the type test into code, but - instead just saves the type in a lexical closure and interprets it - at runtime. - To exercise the problem, compile and load - (cl:in-package :cl-user) - (defstruct foo - (bar (error "missing") :type bar)) - (defvar *foo*) - (defun wastrel1 (x) - (loop (setf (foo-bar *foo*) x))) - (defstruct bar) - (defvar *bar* (make-bar)) - (defvar *foo* (make-foo :bar *bar*)) - (defvar *setf-foo-bar* #'(setf foo-bar)) - (defun wastrel2 (x) - (loop (funcall *setf-foo-bar* x *foo*))) - then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and - use BACKTRACE, to see it's spending all essentially all its time - in %TYPEP and VALUES-SPECIFIER-TYPE and so forth. - One possible solution would be simply to give up on - representing structure slot accessors as functions, and represent - them as macroexpansions instead. This can be inconvenient for users, - but it's not clear that it's worse than trying to help by expanding - into a horribly inefficient implementation. - As a workaround for the problem, #'(SETF FOO) expressions - can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where -(defmacro efficient-setf-function (place-function-name) - (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name) - ;; a workaround for the problem, encouraging the - ;; inline expansion of the structure accessor, so - ;; that the compiler can optimize its type test - (let ((new-value (gensym "NEW-VALUE-")) - (structure-value (gensym "STRUCTURE-VALUE-"))) - `(lambda (,new-value ,structure-value) - (setf (,place-function-name ,structure-value) - ,new-value)))) - ;; no problem, can just use the ordinary expansion - `(function (setf ,place-function-name)))) - -100: - There's apparently a bug in CEILING optimization which caused - Douglas Crosher to patch the CMU CL version. Martin Atzmueller - applied the patches to SBCL and they didn't seem to cause problems - (as reported sbcl-devel 2001-05-04). However, since the patches - modify nontrivial code which was apparently written incorrectly - the first time around, until regression tests are written I'm not - comfortable merging the patches in the CVS version of SBCL. - -108: - (TIME (ROOM T)) reports more than 200 Mbytes consed even for - a clean, just-started SBCL system. And it seems to be right: - (ROOM T) can bring a small computer to its knees for a *long* - time trying to GC afterwards. Surely there's some more economical - way to implement (ROOM T). - - Daniel Barlow doesn't know what fixed this, but observes that it - doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T) - in a fresh SBCL causes - - debugger invoked on a SB-INT:BUG in thread 5911: - failed AVER: "(SAP= CURRENT END)" - - unless a GC has happened beforehand. - -117: - When the compiler inline expands functions, it may be that different - kinds of return values are generated from different code branches. - E.g. an inline expansion of POSITION generates integer results - from one branch, and NIL results from another. When that inline - expansion is used in a context where only one of those results - is acceptable, e.g. - (defun foo (x) - (aref *a1* (position x *a2*))) - and the compiler can't prove that the unacceptable branch is - never taken, then bogus type mismatch warnings can be generated. - If you need to suppress the type mismatch warnings, you can - suppress the inline expansion, - (defun foo (x) - #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings - (aref *a1* (position x *a2*))) - or, sometimes, suppress them by declaring the result to be of an - appropriate type, - (defun foo (x) - (aref *a1* (the integer (position x *a2*)))) - - This is not a new compiler problem in 0.7.0, but the new compiler - transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it - more conspicuous. If you don't need performance from these functions, - and the bogus warnings are a nuisance for you, you can return to - your pre-0.7.0 state of grace with - #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117.. - - (see also bug 279) - -118: - as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: - (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) - (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T - when of course it should be NIL. (He says it only fails for X86, - not SPARC; dunno about Alpha.) - - Also, "the same problem exists for LONG-FLOAT-EPSILON, - DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though - for the -negative- the + is replaced by a - in the test)." - - Raymond Toy comments that this is tricky on the X86 since its FPU - uses 80-bit precision internally. - - Bruno Haible comments: - The values are those that are expected for an IEEE double-float - arithmetic. The problem appears to be that the rounding is not - IEEE on x86 compliant: namely, values are first rounded to 64 - bits mantissa precision, then only to 53 bits mantissa - precision. This gives different results than rounding to 53 bits - mantissa precision in a single step. - - The quick "fix", to permanently change the FPU control word from - 0x037f to 0x027f, will give problems with the fdlibm code that is - used for computing transcendental functions like sinh() etc. - so maybe we need to change the FPU control word to that for Lisp - code, and adjust it to the safe 0x037f for calls to C? - -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 - 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. - Unfortunately I (WHN) don't see any simple way to detect this - condition in order to issue such an error, so for the meantime - SBCL just does this weird broken "conforming" thing. - - The ANSI standard says, in the definition of the special operator - MACROLET, - The macro-expansion functions defined by MACROLET are defined - in the lexical environment in which the MACROLET form appears. - Declarations and MACROLET and SYMBOL-MACROLET definitions affect - 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. - Then it seems to contradict itself by giving the example - (defun foo (x flag) - (macrolet ((fudge (z) - ;The parameters x and flag are not accessible - ; at this point; a reference to flag would be to - ; the global variable of that name. - ` (if flag (* ,z ,z) ,z))) - ;The parameters x and flag are accessible here. - (+ x - (fudge x) - (fudge (+ x 1))))) - The comment "a reference to flag would be to the global variable - of the same name" sounds like good behavior for the system to have. - 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) - (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, - 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. - -141: "pretty printing and backquote" - a. - * '``(FOO ,@',@S) - ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - - c. (reported by Paul F. Dietz) - * '`(lambda ,x) - `(LAMBDA (SB-IMPL::BACKQ-COMMA X)) - -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - -145: - a. - ANSI allows types `(COMPLEX ,FOO) to use very hairy values for - FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL - COMPLEX implementation didn't deal with this, and hasn't been - upgraded to do so. (This doesn't seem to be a high priority - conformance problem, since seems hard to construct useful code - where it matters.) - - b. (fixed in 0.8.3.43) - -146: - Floating point errors are reported poorly. E.g. on x86 OpenBSD - with sbcl-0.7.1, - * (expt 2.0 12777) - debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION: - An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled. - No traps are enabled? How can this be? - It should be possible to be much more specific (overflow, division - by zero, etc.) and of course the "How can this be?" should be fixable. - - See also bugs #45.c and #183 - -162: - (reported by Robert E. Brown 2002-04-16) - When a function is called with too few arguments, causing the - debugger to be entered, the uninitialized slots in the bad call frame - seem to cause GCish problems, being interpreted as tagged data even - though they're not. In particular, executing ROOM in the - debugger at that point causes AVER failures: - * (machine-type) - "X86" - * (lisp-implementation-version) - "0.7.2.12" - * (typep 10) - ... - 0] (room) - ... - failed AVER: "(SAP= CURRENT END)" - (Christophe Rhodes reports that this doesn't occur on the SPARC, which - isn't too surprising since there are many differences in stack - implementation and GC conservatism between the X86 and other ports.) - - 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 - bogus warnings about errors in the constant folding, e.g. in code - like - (WHEN X - (WRITE-STRING (> X 0) "+" "0")) - compiled in a context where the compiler can prove that X is NIL, - and the compiler complains that (> X 0) causes a type error because - NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this - caused a full WARNING, which made the bug really annoying because then - COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal - code. Since then the warning has been downgraded to STYLE-WARNING, - so it's still a bug but at least it's a little less annoying. - -183: "IEEE floating point issues" - Even where floating point handling is being dealt with relatively - well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the - accrued-exceptions and current-exceptions part of the fp control - word don't seem to bear much relation to reality. E.g. on - SPARC/SunOS: - * (/ 1.0 0.0) - - debugger invoked on condition of type DIVISION-BY-ZERO: - arithmetic error DIVISION-BY-ZERO signalled - 0] (sb-vm::get-floating-point-modes) - - (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) - :ROUNDING-MODE :NEAREST - :CURRENT-EXCEPTIONS NIL - :ACCRUED-EXCEPTIONS (:INEXACT) - :FAST-MODE NIL) - 0] abort - * (sb-vm::get-floating-point-modes) - (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) - :ROUNDING-MODE :NEAREST - :CURRENT-EXCEPTIONS (:INEXACT) - :ACCRUED-EXCEPTIONS (:INEXACT) - :FAST-MODE NIL) - -188: "compiler performance fiasco involving type inference and UNION-TYPE" - (time (compile - nil - '(lambda () - (declare (optimize (safety 3))) - (declare (optimize (compilation-speed 2))) - (declare (optimize (speed 1) (debug 1) (space 1))) - (let ((start 4)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26)) - (print (incf start 28))) - (let ((start 6)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26))) - (let ((start 10)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26)))))) - - This example could be solved with clever enough constraint - propagation or with SSA, but consider - - (let ((x 0)) - (loop (incf x 2))) - - The careful type of X is {2k} :-(. Is it really important to be - able to work with unions of many intervals? - -191: "Miscellaneous PCL deficiencies" - (reported by Alexey Dejneka sbcl-devel 2002-08-04) - a. DEFCLASS does not inform the compiler about generated - functions. Compiling a file with - (DEFCLASS A-CLASS () - ((A-CLASS-X))) - (DEFUN A-CLASS-X (A) - (WITH-SLOTS (A-CLASS-X) A - A-CLASS-X)) - results in a STYLE-WARNING: - undefined-function - SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER| - - APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre - Mai points out that the declamation of functions is in fact - incorrect in some cases (most notably for structure - classes). This means that at present erroneous attempts to use - WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS - won't get the corresponding STYLE-WARNING. - c. (fixed in 0.8.4.23) - -201: "Incautious type inference from compound types" - a. (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" - - b. - * (defun foo (x) - (declare (type (array * (4 4)) x)) - (let ((y x)) - (setq x (make-array '(4 4))) - (adjust-array y '(3 5)) - (= (array-dimension y 0) (eval `(array-dimension ,y 0))))) - FOO - * (foo (make-array '(4 4) :adjustable t)) - NIL - -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. - c. The cross-compiler cannot inline functions defined in a non-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? - -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 - circular arguments; it would be good for the user if they could be - given an error instead (ANSI 17.1.1 allows this behaviour on the part - of the implementation, as conforming code cannot give non-proper - sequences to these functions. MAP also has this problem (and - solution), though arguably the convenience of being able to do - (MAP 'LIST '+ FOO '#1=(1 . #1#)) - might be classed as more important (though signalling an error when - all of the arguments are circular is probably desireable). - -213: "Sequence functions and type checking" - a. (fixed in 0.8.4.36) - b. MAP, when given a type argument that is SUBTYPEP LIST, does not - check that it will return a sequence of the given type. Fixing - it along the same lines as the others (cf. work done around - sbcl-0.7.8.45) is possible, but doing so efficiently didn't look - entirely straightforward. - c. All of these functions will silently accept a type of the form - (CONS INTEGER *) - whether or not the return value is of this type. This is - probably permitted by ANSI (see "Exceptional Situations" under - ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not - know about this escape clause, so code of the form - (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) - can erroneously return T. - -215: ":TEST-NOT handling by functions" - a. FIND and POSITION currently signal errors when given non-NIL for - both their :TEST and (deprecated) :TEST-NOT arguments, but by - ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2 - means that the effect is "unpredictable but harmless". It's not - clear what that actually means; it may preclude conforming - implementations from signalling errors. - b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument - when conflict occurs. As a quality of implementation issue, it - might be preferable to treat :TEST and :TEST-NOT as being in some - sense the same &KEY, and effectively take the first test function in - the argument list. - c. Again, a quality of implementation issue: it would be good to issue a - STYLE-WARNING at compile-time for calls with :TEST-NOT, and a - WARNING for calls with both :TEST and :TEST-NOT; possibly this - latter should be WARNed about at execute-time too. - -216: "debugger confused by frames with invalid number of arguments" - In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q - leaves the system confused, enough so that (QUIT) no longer works. - It's as though the process of working with the uninitialized slot in - the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may - not be the actual problem. (CMU CL 18c doesn't have problems with this.) - - This is probably the same bug as 162 - -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) - - Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. - - (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)) - (declaim (inline acc)) - (defun acc (c) - (the number (car c))) - - (defun foo (x y) - (values (locally (declare (optimize (safety 0))) - (acc x)) - (locally (declare (optimize (safety 3))) - (acc y)))) - - (foo '(nil) '(t)) => NIL, T. - -237: "Environment arguments to type functions" - a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and - UPGRADED-COMPLEX-PART-TYPE now have an optional environment - argument, but they ignore it completely. This is almost - certainly not correct. - b. Also, the compiler's optimizers for TYPEP have not been informed - about the new argument; consequently, they will not transform - calls of the form (TYPEP 1 'INTEGER NIL), even though this is - just as optimizeable as (TYPEP 1 'INTEGER). - -238: "REPL compiler overenthusiasm for CLOS code" - From the REPL, - * (defclass foo () ()) - * (defmethod bar ((x foo) (foo foo)) (call-next-method)) - causes approximately 100 lines of code deletion notes. Some - discussion on this issue happened under the title 'Three "interesting" - bugs in PCL', resulting in a fix for this oververbosity from the - compiler proper; however, the problem persists in the interactor - because the notion of original source is not preserved: for the - compiler, the original source of the above expression is (DEFMETHOD - BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the - compiler gets its hands on the code needing compilation from the REPL, - it has been macroexpanded several times. - - A symptom of the same underlying problem, reported by Tony Martinez: - * (handler-case - (with-input-from-string (*query-io* " no") - (yes-or-no-p)) - (simple-type-error () 'error)) - ; in: LAMBDA NIL - ; (SB-KERNEL:FLOAT-WAIT) - ; - ; note: deleting unreachable code - ; compilation unit finished - ; printed 1 note - -241: "DEFCLASS mysteriously remembers uninterned accessor names." - (from tonyms on #lisp IRC 2003-02-25) - In sbcl-0.7.12.55, typing - (defclass foo () ((bar :accessor foo-bar))) - (profile foo-bar) - (unintern 'foo-bar) - (defclass foo () ((bar :accessor foo-bar))) - gives the error message - "#:FOO-BAR already names an ordinary function or a macro." - So it's somehow checking the uninterned old accessor name instead - of the new requested accessor name, which seems broken to me (WHN). - -242: "WRITE-SEQUENCE suboptimality" - (observed from clx performance) - In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type - (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type - (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. - -243: "STYLE-WARNING overenthusiasm for unused variables" - (observed from clx compilation) - In sbcl-0.7.14, in the presence of the macros - (DEFMACRO FOO (X) `(BAR ,X)) - (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL) - somewhat surprising style warnings are emitted for - (COMPILE NIL '(LAMBDA (Y) (FOO Y))): - ; in: LAMBDA (Y) - ; (LAMBDA (Y) (FOO Y)) - ; - ; caught STYLE-WARNING: - ; The variable Y is defined but never used. - -245: bugs in disassembler - b. On X86 operand size prefix is not recognized. - -251: - (defun foo (&key (a :x)) - (declare (fixnum a)) - a) - - does not cause a warning. (BTW: old SBCL issued a warning, but for a - function, which was never called!) - -256: - Compiler does not emit warnings for - - a. (lambda () (svref (make-array 8 :adjustable t) 1)) - - b. (lambda (x) - (list (let ((y (the real x))) - (unless (floatp y) (error "")) - y) - (integer-length x))) - - c. (lambda (x) - (declare (optimize (debug 0))) - (declare (type vector x)) - (list (fill-pointer x) - (svref x 1))) - -257: - Complex array type does not have corresponding type specifier. - - This is a problem because the compiler emits optimization notes when - you use a non-simple array, and without a type specifier for hairy - array types, there's no good way to tell it you're doing it - intentionally so that it should shut up and just compile the code. - - Another problem is confusing error message "asserted type ARRAY - conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during - compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))). - - The last problem is that when type assertions are converted to type - checks, types are represented with type specifiers, so we could lose - complex attribute. (Now this is probably not important, because - currently checks for complex arrays seem to be performed by - callees.) - -259: - (compile nil '(lambda () (aref (make-array 0) 0))) compiles without - warning. Analogous cases with the index and length being equal and - greater than 0 are warned for; the problem here seems to be that the - type required for an array reference of this type is (INTEGER 0 (0)) - which is canonicalized to NIL. - -260: - a. - (let* ((s (gensym)) - (t1 (specifier-type s))) - (eval `(defstruct ,s)) - (type= t1 (specifier-type s))) - => NIL, NIL - - (fixed in 0.8.1.24) - - 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. - -266: - David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix - behaviour of streams with element-type (SIGNED-BYTE 8). The patch - looks reasonable, if not obviously correct; however, it caused the - PPC/Linux port to segfault during warm-init while loading - src/pcl/std-class.fasl. A workaround patch was made, but it would - be nice to understand why the first patch caused problems, and to - fix the cause if possible. - -268: "wrong free declaration scope" - The following code must signal type error: - - (locally (declare (optimize (safety 3))) - (flet ((foo (x &optional (y (car x))) - (declare (optimize (safety 0))) - (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: - - (defun foo (x) - (declare (integer x)) - (declare (optimize speed)) - (typecase x - (fixnum "hala") - (fixnum "buba") - (bignum "hip") - (t "zuz"))) - -273: - Compilation of the following two forms causes "X is unbound" error: - - (symbol-macrolet ((x pi)) - (macrolet ((foo (y) (+ x y))) - (declaim (inline bar)) - (defun bar (z) - (* z (foo 4))))) - (defun quux (z) - (bar z)) - - (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.) - -274: - CLHS says that type declaration of a symbol macro should not affect - its expansion, but in SBCL it does. (If you like magic and want to - fix it, don't forget to change all uses of MACROEXPAND to - MACROEXPAND*.) - -275: - The following code (taken from CLOCC) takes a lot of time to compile: - - (defun foo (n) - (declare (type (integer 0 #.large-constant) n)) - (expt 1/10 n)) - - (fixed in 0.8.2.51, but a test case would be good) - -276: - (defmethod fee ((x fixnum)) - (setq x (/ x 2)) - x) - (fee 1) => type error - - (taken from CLOCC) - -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) - -279: type propagation error -- correctly inferred type goes astray? - In sbcl-0.8.3 and sbcl-0.8.1.47, the warning - The binding of ABS-FOO is a (VALUES (INTEGER 0 0) - &OPTIONAL), not a (INTEGER 1 536870911) - is emitted when compiling this file: - (declaim (ftype (function ((integer 0 #.most-positive-fixnum)) - (integer #.most-negative-fixnum 0)) - foo)) - (defun foo (x) - (- x)) - (defun bar (x) - (let* (;; Uncomment this for a type mismatch warning indicating - ;; that the type of (FOO X) is correctly understood. - #+nil (fs-foo (float-sign (foo x))) - ;; Uncomment this for a type mismatch warning - ;; indicating that the type of (ABS (FOO X)) is - ;; correctly understood. - #+nil (fs-abs-foo (float-sign (abs (foo x)))) - ;; something wrong with this one though - (abs-foo (abs (foo x)))) - (declare (type (integer 1 100) abs-foo)) - (print abs-foo))) - - (see also bug 117) - -280: bogus WARNING about duplicate function definition - In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline, - e.g. by - (declaim (inline bs.min)) - (defun bs.min (bases) nil) - before compiling the file below, the compiler warns - Duplicate definition for BS.MIN found in one static - unit (usually a file). - when compiling - (declaim (special *minus* *plus* *stagnant*)) - (defun b.*.min (&optional (x () xp) (y () yp) &rest rest) - (bs.min avec)) - (define-compiler-macro b.*.min (&rest rest) - `(bs.min ,@rest)) - (defun afish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min 0)) - (vector (values #'bs.min *plus*))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - (defun bfish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min *minus*)) - (vector (values #'bs.min 0))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - -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 - 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 - -284: Thread safety: special variables - There are lots of special variables in SBCL, and I feel sure that at - least some of them are indicative of potentially thread-unsafe - parts of the system. See doc/internals/notes/threading-specials - -286: "recursive known functions" - Self-call recognition conflicts with known function - recognition. Currently cross compiler and target COMPILE do not - recognize recursion, and in target compiler it can be disabled. We - can always disable it for known functions with RECURSIVE attribute, - but there remains a possibility of a function with a - (tail)-recursive simplification pass and transforms/VOPs for base - cases. - -287: PPC/Linux miscompilation or corruption in first GC - When the runtime is compiled with -O3 on certain PPC/Linux machines, a - segmentation fault is reported at the point of first triggered GC, - during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround, - the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely - that this merely obscures, not solves, the underlying problem; as and when - underlying problems are fixed, it would be worth trying again to provoke - this problem. - -288: fundamental cross-compilation issues (from old UGLINESS file) - Using host floating point numbers to represent target floating point - numbers, or host characters to represent target characters, is - theoretically shaky. (The characters are OK as long as the characters - are in the ANSI-guaranteed character set, though, so they aren't a - real problem as long as the sources don't need anything but that; - the floats are a real problem.) - -289: "type checking and source-transforms" - a. - (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good)))) - signals type error. - - Our policy is to check argument types at the moment of a call. It - disagrees with ANSI, which says that type assertions are put - immediately onto argument expressions, but is easier to implement in - IR1 and is more compatible to type inference, inline expansion, - etc. IR1-transforms automatically keep this policy, but source - transforms for associative functions (such as +), being applied - during IR1-convertion, do not. It may be tolerable for direct calls - (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant. - - b. Another aspect of this problem is efficiency. [x y + z +] - requires less registers than [x y z + +]. This transformation is - currently performed with source transforms, but it would be good to - also perform it in IR1 optimization phase. - -290: Alpha floating point and denormalized traps - In SBCL 0.8.3.6x on the alpha, we work around what appears to be a - hardware or kernel deficiency: the status of the enable/disable - denormalized-float traps bit seems to be ambiguous; by the time we - get to os_restore_fp_control after a trap, denormalized traps seem - to be enabled. Since we don't want a trap every time someone uses a - denormalized float, in general, we mask out that bit when we restore - 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 - (loop for d of-type double-float from 0d0 to 10d0 by x collect d) - compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL - (0))). However, an integral value of X should be legal, because - successive adds of integers to double-floats produces double-floats, - so none of the type restrictions in the code is violated. - -300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE - argument type only after having read a character. This is caused - with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem - exists with =, /=, <, >, <=, >=. They were fixed, but it is probably - less error prone to have EXPLICIT-CHECK be a local declaration, - being put into the definition, instead of an attribute being kept in - a separate file; maybe also put it into SB-EXT? - -301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise - in NOTE-ASSUMED-TYPES - In sbcl-0.8.7.32, compiling the file - (defun foo (x y) - (declare (type integer x)) - (declare (type (vector (or hash-table bit)) y)) - (bletch 2 y)) - (defun bar (x y) - (declare (type integer x)) - (declare (type (simple-array base (2)) y)) - (bletch 1 y)) - 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 - (block foo - (multiple-value-prog1 - (eval '(values :a :b :c)) - (catch 'bar - (if (> x 0) - (return-from foo - (eval `(if (> ,x 1) - 1 - (throw 'bar (values 3 4))))))))))) - - (BUU 1) returns garbage. - - 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) - (type (or (array cons) (array vector)) x)) - (elt (aref x 0) 0)) - (foo #((0))) => TYPE-ERROR - - relatedly, - - b.(subtypep - 'array - `(or - ,@(loop for x across sb-vm:*specialized-array-element-type-properties* - 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) - (values-list (make-list 1000000)), on x86/linux, signals a stack - exhaustion condition, despite MULTIPLE-VALUES-LIMIT being - significantly larger than 1000000. There are probably similar - dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp - 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. - -312: - (reported by Jon Dyte) - SBCL issues a warning "Duplicate definition of FOO" compiling - - (declaim (inline foo)) - (defun foo (x) - (1+ x)) - (defun bar (y) - (list (foo y) (if (> y 1) (funcall (if (> y 0) #'foo #'identity) y)))) - - (probably related to the bug 280.) - -313: "source-transforms are Lisp-1" - (fixed in 0.8.10.2) - -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. - ;; - ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is - ;; initialized to the result of evaluating form1. 6.1.7.2 says that - ;; initially clauses are evaluated in the loop prologue, which precedes all - ;; loop code except for the initial settings provided by with, for, or as. - (loop :for x = 0 :then (1+ x) - :for y = (1+ x) :then (ash y 1) - :for z :across #(1 3 9 27 81 243) - :for w = (+ x y z) - :initially (assert (zerop x)) :initially (assert (= 2 w)) - :until (>= w 100) :collect w) - Expected: (2 6 15 38) - Got: ERROR - -315: "no bounds check for access to displaced array" - reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP - test suite. - (locally (declare (optimize (safety 3) (speed 0))) - (let* ((x (make-array 10 :fill-pointer 4 :element-type 'character - :initial-element #\space :adjustable t)) - (y (make-array 10 :fill-pointer 4 :element-type 'character - :displaced-to x))) - (adjust-array x '(5)) - (char y 5))) - - SBCL 0.8.10 elides the bounds check somewhere along the line, and - returns #\Nul (where an error would be much preferable, since a test - of that form but with (setf (char y 5) #\Space) potentially corrupts - the heap and certainly confuses the world if that string is used by - C code. - -316: "SHIFTF and multiple values" - reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP - test suite. - (shiftf (values x y) (values y x)) - gives an error in sbcl-0.8.10. - - Parts of the explanation of SHIFTF in ANSI CL talk about multiple - store variables, and the X3J13 vote - SETF-MULTIPLE-STORE-VARIABLES:ALLOW also says that SHIFTF should - support multiple value places. - -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 - ...#