X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=68cbee7b93df6dc0b501da71d5db4f41c0c63e83;hb=4fc9d21ae1d8a6a2f8ff70f589d5da103203de13;hp=fbfc496ee72ee05c0ecb829742d9fc4ce0df8fe5;hpb=c3f281f5c34b55170ac43a4679f1528b8bb7c703;p=sbcl.git diff --git a/BUGS b/BUGS index fbfc496..68cbee7 100644 --- a/BUGS +++ b/BUGS @@ -5,8 +5,8 @@ Bugs can be reported on the help mailing list or on the development mailing list sbcl-devel@lists.sourceforge.net -Please please please include enough information in a bug report -that someone reading it can reproduce the problem, i.e. don't write +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 @@ -22,102 +22,76 @@ but instead the program loops endlessly instead of printing the object. -KNOWN PORT-SPECIFIC BUGS +NOTES: -OpenBSD-1: - The breakpoint-based TRACE facility doesn't work properly - in the OpenBSD port of sbcl-0.6.7. +There is also some information on bugs in the manual page and +in the TODO file. Eventually more such information may move here. -KNOWN BUGS RELATED TO THE IR1 INTERPRETER +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). -At some point, the pure interpreter (aka the "IR1 interpreter") will -probably go away (replaced by constructs like - (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) -and at that time these bugs should go away automatically. Until then, -they'll probably remain, since they're not considered urgent. -IR1-1: - The FUNCTION special operator doesn't check properly whether its - argument is a function name. E.g. (FUNCTION (X Y)) returns a value - instead of failing with an error. (Later attempting to funcall the - value does cause an error.) - -IR1-2: - COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -OTHER KNOWN BUGS: - -(There is also some information on bugs in the manual page and in the -TODO file. Eventually more such information may move here.) - -1: - Failure in initialization files is not handled gracefully -- it's - a throw to TOP-LEVEL-CATCHER, which is not caught until we enter - TOPLEVEL-REPL. Code should be added to catch such THROWs even when - we're not in TOPLEVEL-REPL and do *something* with them (probably - complaining about an error outside TOPLEVEL-REPL, perhaps printing - a BACKTRACE, then terminating execution of SBCL). +KNOWN BUGS OF NO SPECIAL CLASS: 2: - DEFSTRUCT should almost certainly overwrite the old LAYOUT information + DEFSTRUCT almost certainly should overwrite the old LAYOUT information instead of just punting when a contradictory structure definition - is loaded. + 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: - It should cause a STYLE-WARNING, not a full WARNING, when a structure - slot default value does not match the declared structure slot type. - (The current behavior is consistent with SBCL's behavior elsewhere, - and would not be a problem, except that the other behavior is - specifically required by the ANSI spec.) - -4: - It should cause a STYLE-WARNING, not a WARNING, when the system ignores - an FTYPE proclamation for a slot accessor. - -5: - Error reporting on various stream-requiring operations is not - very good when the stream argument has the wrong type, because - the operation tries to fall through to Gray stream code, and then - dies because it's undefined. E.g. - (PRINT-UNREADABLE-OBJECT (*STANDARD-OUTPUT* 1)) - gives the error message - error in SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: - The function SB-IMPL::STREAM-WRITE-STRING is undefined. - It would be more useful and correct to signal a TYPE-ERROR: - not a STREAM: 1 - (It wouldn't be terribly difficult to write stubs for all the - Gray stream functions that the old CMU CL code expects, with - each stub just raising the appropriate TYPE-ERROR.) + 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. 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. + 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, e.g. + ERROR). 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 () 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 will compile without complaint and work correctly either + on SBCL or on a completely compliant Common Lisp system. 6: bogus warnings about undefined functions for magic functions like SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files - like src/code/float.lisp + like src/code/float.lisp. Fixing this will probably require + straightening out enough bootstrap consistency issues that + the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*. + Instead, the cross-compiler runs in a slightly flaky state + which is sane enough to compile SBCL itself, but which is + also unstable in several ways, including its inability + to really grok function declarations. 7: The "byte compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a single "byte compiling top-level forms:" line. -8: - Compiling a file containing the erroneous program - (DEFSTRUCT FOO - A - B) - (DEFSTRUCT (BAR (:INCLUDE FOO)) - A - B) - gives only the not-very-useful message - caught ERROR: - (during macroexpansion) - Condition PROGRAM-ERROR was signalled. - (The specific message which says that the problem was duplicate - slot names gets lost.) - 9: The handling of IGNORE declarations on lambda list arguments of DEFMETHOD is at least weird, and in fact seems broken and useless. @@ -199,39 +173,6 @@ TODO file. Eventually more such information may move here.) (Also, when this is fixed, we can enable the code in PROCLAIM which checks for incompatible FTYPE redeclarations.) -16: - The ANSI spec says that CONS can be a compound type spec, e.g. - (CONS FIXNUM REAL). SBCL doesn't support this. - -17: - from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000: -I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical -pathname, the type of the corresponding compiled file is X86F: - * (compile-file "/home/paolo/lisp/tools/foo") - Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm. - Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm - Converted SQUARE. - Compiling DEFUN SQUARE: - Byte Compiling Top-Level Form: - /home/paolo/lisp/tools/foo.x86f written. - Compilation finished in 0:00:00. - #p"/home/paolo/lisp/tools/foo.x86f" - NIL - NIL -But when the function is called with a logical pathname, the file type -becomes FASL: - * (compile-file "tools:foo") - Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm. - Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm - Converted SQUARE. - Compiling DEFUN SQUARE: - Byte Compiling Top-Level Form: - TOOLS:FOO.FASL written. - Compilation finished in 0:00:00. - #p"/home/paolo/lisp/tools/foo.fasl" - NIL - NIL - 18: from DTC on the CMU CL mailing list 25 Feb 2000: ;;; Compiler fails when this file is compiled. @@ -282,15 +223,6 @@ becomes FASL: DTC's recommended workaround from the mailing list 3 Mar 2000: (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) -21: - There's probably a bug in the compiler handling of special variables - in closures, inherited from the CMU CL code, as reported on the - CMU CL mailing list. There's a patch for this on the CMU CL - mailing list too: - Message-ID: <38C8E188.A1E38B5E@jeack.com.au> - Date: Fri, 10 Mar 2000 22:50:32 +1100 - From: "Douglas T. Crosher" - 22: The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block", says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used @@ -355,16 +287,6 @@ returning an array as first value always. Process inferior-lisp exited abnormally with code 1 I haven't noticed a repeatable case of this yet. -28: - The system accepts DECLAIM in most places where DECLARE would be - accepted, without even issuing a warning. ANSI allows this, but since - it's fairly easy to mistype DECLAIM instead of DECLARE, and the - meaning is rather different, and it's unlikely that the user - has a good reason for doing DECLAIM not at top level, it would be - good to issue a STYLE-WARNING when this happens. A possible - fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level, - or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level. - 29: some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling (DEFUN BAR? (X) @@ -383,11 +305,6 @@ returning an array as first value always. The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed. This is still present in sbcl-0.6.8. -30: - The CMU CL reader code takes liberties in binding the standard read table - when reading the names of characters. Tim Moore posted a patch to the - CMU CL mailing list Mon, 22 May 2000 21:30:41 -0700. - 31: In some cases the compiler believes type declarations on array elements without checking them, e.g. @@ -419,6 +336,11 @@ returning an array as first value always. also report on closures, telling about the values of the bound variables. 34: + WHN test case: Compile this file: + (eval-when (:compile-toplevel :load-toplevel :execute) + (defclass a-class () (a))) + (defconstant +a-constant+ (make-instance 'a-class)) + (defconstant +another-constant+ (vector +a-constant+)) as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000: $ cat xx.lisp (defconstant +a-constant+ (make-instance 'a-class)) @@ -479,73 +401,19 @@ returning an array as first value always. make sense to add another flag (CHECKED?) to DEFKNOWN to identify functions which *do* check their argument types.) -36: - As pointed out by Martin Cracauer on the CMU CL mailing list - 13 Jun 2000, the :FILE-LENGTH operation for - FD-STREAM-MISC-ROUTINE is broken for large files: it says - (THE INDEX SIZE) even though SIZE can be larger than INDEX. - -37: - In SBCL 0.6.5 (and CMU CL 18b) compiling and loading - (in-package :cl-user) - (declaim (optimize (safety 3) - (debug 3) - (compilation-speed 2) - (space 1) - (speed 2) - #+nil (sb-ext:inhibit-warnings 2))) - (declaim (ftype (function * (values)) emptyvalues)) - (defun emptyvalues (&rest rest) (declare (ignore rest)) (values)) - (defstruct foo x y) - (defgeneric assertoid ((x t))) - (defmethod assertoid ((x t)) "just a placeholder") - (defun bar (ht) - (declare (type hash-table ht)) - (let ((res - (block blockname - (progn - (prog1 - (emptyvalues) - (assertoid (hash-table-count ht))))))) - (unless (typep res 'foo) - (locally - (common-lisp-user::bad-result-from-assertive-typed-fun - 'bar - res))))) - then executing - (bar (make-hash-table)) - causes the failure - Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: - the function C::%INSTANCE-TYPEP is undefined. - %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for - some reason -- the (VALUES) return value declaration? -- the optimizer is - confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist - as a function) instead. - 38: DEFMETHOD doesn't check the syntax of &REST argument lists properly, accepting &REST even when it's not followed by an argument name: (DEFMETHOD FOO ((X T) &REST) NIL) -39: - On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote - - Hannu Rummukainen wrote: - ... - > There's something weird going on with the compilation of the attached - > code. Compiling and loading the file in a fresh lisp, then invoking - > (test-it) gives - Thanks for the bug report, nice to have this one fixed. It was a bug - in the x86 backend, the < VOP. A fix has been committed to the main - source, see the file compiler/x86/float.lisp. - - Probably the same bug exists in SBCL. - 40: TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel, so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET)) returns (VALUES T T). Probably it should be an error instead, complaining that the type SOMETHING-NOT-DEFINED-YET is not defined. + Or perhaps UPGRADED-ARRAY-ELEMENT-TYPE should just fail when a type + isn't defined yet. (What if the definition of + SOMETHING-NOT-DEFINED-YET turns out to be SINGLE-FLOAT?) 41: TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in @@ -712,9 +580,6 @@ SBCL: (("blah") ("blah2")) b: READ should probably return READER-ERROR, not the bare arithmetic error, when input a la "1/0" or "1e1000" causes an arithmetic error. - c: (BUTLAST NIL) should return NIL. (This appears to be a compiler - bug, since the definition of BUTLAST, when interpreted, does - give (BUTLAST NIL)=>NIL.) 52: It has been reported (e.g. by Peter Van Eynde) that there are @@ -746,18 +611,323 @@ SBCL: (("blah") ("blah2")) Error in function C::GET-LAMBDA-TO-COMPILE: # was defined in a non-null environment. -57: - In sbcl-0.6.7, the compiler accepted a bogus declaration - (TYPE INDEX LENGTH) in the definition of BUTLAST, and then died - with infinite regress of errors when the BUTLAST function was - executed with a LIST=NIL which would cause LENGTH to be -1. - I fixed the bogus declaration, but I should come back and see - whether the system's inability to recover from the bogus declaration - (by signalling a TYPE-ERROR and dropping into the debugger) was - a compiler problem which remains to be fixed, or one of the - unrelated infinite-regress-errors problems, many related to - revised signal handling, which were fixed around the same time. - 58: (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL + +59: + CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting + current working directory). And there's no supported way to update + or query the current working directory (a la Unix "chdir" and "pwd"), + which is functionality that ILISP needs (and currently gets with low-level + hacks). + +60: + The debugger LIST-LOCATIONS command doesn't 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. + +62: + The compiler is supposed to do type inference well enough that + the declaration in + (TYPECASE X + ((SIMPLE-ARRAY SINGLE-FLOAT) + (LOCALLY + (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X)) + ..)) + ..) + is redundant. However, as reported by Juan Jose Garcia Ripoll for + CMU CL, it sometimes doesn't. Adding declarations is a pretty good + workaround for the problem for now, but can't be done by the TYPECASE + macros themselves, since it's too hard for the macro to detect + assignments to the variable within the clause. + Note: The compiler *is* smart enough to do the type inference in + many cases. This case, derived from a couple of MACROEXPAND-1 + calls on Ripoll's original test case, + (DEFUN NEGMAT (A) + (DECLARE (OPTIMIZE SPEED (SAFETY 0))) + (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL + (LET ((LENGTH (ARRAY-TOTAL-SIZE A))) + (LET ((I 0) (G2554 LENGTH)) + (DECLARE (TYPE REAL G2554) (TYPE REAL I)) + (TAGBODY + SB-LOOP::NEXT-LOOP + (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP)) + (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I))) + (GO SB-LOOP::NEXT-LOOP) + SB-LOOP::END-LOOP)))))) + demonstrates the problem; but the problem goes away if the TAGBODY + and GO forms are removed (leaving the SETF in ordinary, non-looping + code), or if the TAGBODY and GO forms are retained, but the + assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)). + +63: + Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15 + I am looking into this problem that showed up on the cmucl-help + list. It seems to me that the "implementation specific environment + hacking functions" found in pcl/walker.lisp are completely messed + up. The good thing is that they appear to be barely used within + PCL and the munged environment object is passed to cmucl only + in calls to macroexpand-1, which is probably why this case fails. + SBCL uses essentially the same code, so if the environment hacking + is screwed up, it affects us too. + +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. + +65: + (probably related to bug #70) + As reported by Carl Witty on submit@bugs.debian.org 1999-05-08, + compiling this file +(in-package "CL-USER") +(defun equal-terms (termx termy) + (labels + ((alpha-equal-bound-term-lists (listx listy) + (or (and (null listx) (null listy)) + (and listx listy + (let ((bindings-x (bindings-of-bound-term (car listx))) + (bindings-y (bindings-of-bound-term (car listy)))) + (if (and (null bindings-x) (null bindings-y)) + (alpha-equal-terms (term-of-bound-term (car listx)) + (term-of-bound-term (car listy))) + (and (= (length bindings-x) (length bindings-y)) + (prog2 + (enter-binding-pairs (bindings-of-bound-term (car listx)) + (bindings-of-bound-term (car listy))) + (alpha-equal-terms (term-of-bound-term (car listx)) + (term-of-bound-term (car listy))) + (exit-binding-pairs (bindings-of-bound-term (car listx)) + (bindings-of-bound-term (car listy))))))) + (alpha-equal-bound-term-lists (cdr listx) (cdr listy))))) + + (alpha-equal-terms (termx termy) + (if (and (variable-p termx) + (variable-p termy)) + (equal-bindings (id-of-variable-term termx) + (id-of-variable-term termy)) + (and (equal-operators-p (operator-of-term termx) (operator-of-term termy)) + (alpha-equal-bound-term-lists (bound-terms-of-term termx) + (bound-terms-of-term termy)))))) + + (or (eq termx termy) + (and termx termy + (with-variable-invocation (alpha-equal-terms termx termy)))))) + causes an assertion failure + The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER) + (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed. + + Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test + case with the same problem: +(defun parse-fssp-alignment () + ;; Given an FSSP alignment file named by the argument . . . + (labels ((get-fssp-char () + (get-fssp-char)) + (read-fssp-char () + (get-fssp-char))) + ;; Stub body, enough to tickle the bug. + (list (read-fssp-char) + (read-fssp-char)))) + +66: + ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be + a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: + (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3) + This also leads to funny behavior when derived type specifiers + are used, as originally reported by Milan Zamazal for CMU CL (on the + Debian bugs mailing list (?) 2000-02-27), then reported by Martin + Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net): + (DEFTYPE FOO () 'SIMPLE-ARRAY) + (CONCATENATE 'FOO #(1 2) '(3)) + => # is a bad type specifier for + sequence functions. + The derived type specifier FOO should act the same way as the + built-in type SIMPLE-ARRAY here, but it doesn't. That problem + doesn't seem to exist for sequence types: + (DEFTYPE BAR () 'SIMPLE-VECTOR) + (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) + +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. + +68: + As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23, + SXHASH returns the same value for all non-STRUCTURE-OBJECT instances, + notably including all PCL instances. There's a limit to how much + SXHASH can do to return unique values for instances, but at least + it should probably look at the class name, the way that it does + for STRUCTURE-OBJECTs. + +69: + As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22, + > There remains one issue, that is a bug in SBCL: + > According to my interpretation of the spec, the ":" and "@" modifiers + > should appear _after_ the comma-seperated arguments. + > Well, SBCL (and CMUCL for that matter) accept + > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1")) + > where the correct way (IMHO) should be + > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1")) + Probably SBCL should stop accepting the "~:8D"-style format arguments, + or at least issue a warning. + +70: + (probably related to bug #65) + The compiler doesn't like &OPTIONAL arguments in LABELS and FLET + forms. E.g. + (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL)) + (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL)) + (LET ((ITEM (FIRST SEQ))) + (COND ((NULL SEQ) + (VALUES NIL NIL)) + ((FUNCALL TEST OBJ ITEM) + (VALUES VAL SEQ)) + (T + (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM)))))))) + (FIND-ITEM ITEM SEQUENCE TEST))) + from David Young's bug report on cmucl-help@cons.org 30 Nov 2000 + causes sbcl-0.6.9 to fail with + error in function SB-KERNEL:ASSERT-ERROR: + The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER) + (SB-C::LAMBDA-TAIL-SET + (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed. + +71: + (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after + (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with + the previous SPEED policy. This bug will probably get fixed in + 0.6.9.x in a general cleanup of optimization policy. + +72: + (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. + +74: + As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX) + gives a result which isn't COMPLEX. The result type optimizer + for COERCE doesn't know this, perhaps because it was written before + ANSI threw this curveball: the optimizer thinks that COERCE always + returns a result of the specified type. Thus while the interpreted + function + (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX)) + returns the correct result, + (TRICKY 3) => NIL + the compiled function + (COMPILE 'TRICKY) + does not: + (TRICKY 3) => T + +75: + As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, + ANSI says that WITH-OUTPUT-TO-STRING should have a keyword + :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for + WITH-OUTPUT-TO-STRING. + +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. + +80: + The subtle CMU CL bug discussed by Douglas Thomas Crosher on + cmucl-imp@cons.org 29 Jan 2001 sounds like something that probably + still exists in the corresponding SBCL code. + + +KNOWN BUGS RELATED TO THE IR1 INTERPRETER + +(Note: At some point, the pure interpreter (actually a semi-pure +interpreter aka "the IR1 interpreter") will probably go away, replaced +by constructs like + (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) +and at that time these bugs should either go away automatically or +become more tractable to fix. Until then, they'll probably remain, +since some of them aren't considered urgent, and the rest are too hard +to fix as long as so many special cases remain. After the IR1 +interpreter goes away is also the preferred time to start +systematically exterminating cases where debugging functionality +(backtrace, breakpoint, etc.) breaks down, since getting rid of the +IR1 interpreter will reduce the number of special cases we need to +support.) + +IR1-1: + The FUNCTION special operator doesn't check properly whether its + argument is a function name. E.g. (FUNCTION (X Y)) returns a value + instead of failing with an error. (Later attempting to funcall the + value does cause an error.) + +IR1-2: + COMPILED-FUNCTION-P bogusly reports T for interpreted functions: + * (DEFUN FOO (X) (- 12 X)) + FOO + * (COMPILED-FUNCTION-P #'FOO) + T + +IR1-3: + Executing + (DEFVAR *SUPPRESS-P* T) + (EVAL '(UNLESS *SUPPRESS-P* + (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) + (FORMAT T "surprise!")))) + prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be + rewritten from scratch to conform to the ANSI definition, abandoning + the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and + in the original CMU CL source, too). This should be easier to do -- + though still nontrivial -- once the various IR1 interpreter special + cases are gone. + +IR1-3a: + EVAL-WHEN's idea of what's a toplevel form is even more screwed up + than the example in IR1-3 would suggest, since COMPILE-FILE and + COMPILE both print both "right now!" messages when compiling the + following code, + (LAMBDA (X) + (COND (X + (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) + (PRINT "yes! right now!")) + "yes!") + (T + (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) + (PRINT "no! right now!")) + "no!"))) + and while EVAL doesn't print the "right now!" messages, the first + FUNCALL on the value returned by EVAL causes both of them to be printed. + +IR1-4: + The system accepts DECLAIM in most places where DECLARE would be + accepted, without even issuing a warning. ANSI allows this, but since + it's fairly easy to mistype DECLAIM instead of DECLARE, and the + meaning is rather different, and it's unlikely that the user + has a good reason for doing DECLAIM not at top level, it would be + good to issue a STYLE-WARNING when this happens. A possible + fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level, + or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level. + [This is considered an IR1-interpreter-related bug because until + EVAL-WHEN is rewritten, which won't happen until after the IR1 + interpreter is gone, the system's notion of what's a top-level form + and what's not will remain too confused to fix this problem.]