



[bcbcc0]: BUGS Maximize Restore History

Download this file

BUGS    1360 lines (1250 with data), 57.2 kB


Bugs can be reported on the help mailing list
or on the development mailing list

Please include enough information in a bug report that someone reading
it can reproduce the problem, i.e. don't write
but instead
     I compile and load the file
					(LET ((*PRINT-LENGTH* 4))
					  (PRINT X Y)))))
	 X Y)
     then at the command line type
     the program loops endlessly instead of printing the object.


There is also some information on bugs in the manual page and

The gaps in the number sequence belong to old bug descriptions which
other reasons, e.g. because they were moved elsewhere).


  DEFSTRUCT almost certainly should overwrite the old LAYOUT information
  instead of just punting when a contradictory structure definition
  changes their layout, you probably have to rebuild your entire

  ANSI specifies that a type mismatch in a structure slot
  initialization value should not cause a warning.
  mismatches everywhere), and (2) there's a good portable
  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
    default may exist.
  which really understands Common Lisp types) a suitable default
  does exist, in all cases, because the compiler understands the
      (BAR (ERROR "missing :BAR argument")
      (ERROR "missing required argument")) 
  Such code should compile without complaint and work correctly either
  on SBCL or on any other completely compliant Common Lisp system.

  bogus warnings about undefined functions for magic functions like
  like src/code/float.lisp. Fixing this will probably require
  straightening out enough bootstrap consistency issues that
  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.


  Perhaps any number of such consecutive lines ought to turn into a
  single "compiling top-level forms:" line.

  The way that the compiler munges types with arguments together
  weirdness visible to the user:
	(TYPEP 11 'FOO) => T
	(TYPEP 11 'FIXNUM) => T
  The situation is complicated by the presence of Common Lisp types
	(TYPEP 11 'AND) => T
  forbidden (by the ANSI specification of the AND type).

  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)

  checks for incompatible FTYPE redeclarations.)


	(defclass ccc () ())
	(defmethod zut ((c ccc1)) 123)
  In sbcl-, this gives an error, 
	There is no class named CCC1.
  DTC's recommended workaround from the mailing list 3 Mar 2000:

  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.

  The printer doesn't report closures very well. This is true in 
  CMU CL 18b as well:
  and make things like DEFSTRUCT and FLET, which create closures,
  set helpful values into this slot.


  The compiler assumes that any time a function of declared FTYPE
  E.g. compiling and loading
    (DEFUN FOO (X)
      (COND ((> (FACTORIAL X) 1.0E6)
             (FORMAT T "too big~%"))
            ((INTEGERP X)
  then executing
    (FOO 1.5)
    exactly 2.5
  (or (FOO 1000.5), "exactly 1001.5")
  This violates the "declarations are assertions" principle.
  "declarations are assertions" means that lying to the compiler should
  result to be returned. Thus, the compiler should not assume
  that arbitrary functions check their argument types. (It might
  identify functions which *do* check their argument types.)
  (Also, verify that the compiler handles declared function
  return types as assertions.)

	    (VALUES X)))
  where the implementation of the type check in function FOO 

  The definitions of SIGCONTEXT-FLOAT-REGISTER and
  supported on FreeBSD because the floating point state is not saved,
  so they could be supported after all. Very likely 

  (and now SBCL) interpret them as legal types.

  on July 25, 2000:
	   should probably be 1.4012985e-45. In SBCL,
	   than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
	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-
	   on x86/Linux generates the infinities instead. That might or
	   might not be conforming behavior, but it's also inconsistent,
	   signals an error.
	d: (in section12.erg) various forms a la 
	   don't give the right behavior.

	   => #(A B C)
	   In general lengths of array type specifications aren't
	   checked by COERCE, so it fails when the spec is
	   (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
	b: CONCATENATE has the same problem of not checking the length
	   of specified output array types. MAKE-SEQUENCE and MAP and
	   MERGE also have the same problem.
	   should signal TYPE-ERROR.
	i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
	   be used for input and output as needed. It should fail with
	   TYPE-ERROR when handed e.g. the results of
	   the inappropriate positions, but doesn't.
	   not a binary input stream, but instead cheerfully reads from

  DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
	   causes a COMPILER-ERROR.

  SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
	c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
	   it binds is declared SPECIAL inside.

  miscellaneous errors reported by Peter Van Eynde July 25, 2000:
	a: (PROGN
	      (DEFGENERIC FOO03 (X))
	   should give an error, but SBCL allows it.
	b: READ should probably return READER-ERROR, not the bare 
	   arithmetic error, when input a la "1/0" or "1e1000" causes
	   an arithmetic error.

  need to document exactly what metaobject protocol specification

  The implementation of #'+ returns its single argument without
  type checking, e.g. (+ "illegal") => "illegal".

  The debugger LIST-LOCATIONS command doesn't work properly.

  Compiling and loading
    (FAIL 12)
  then requesting a BACKTRACE at the debugger prompt gives no information
  about where in the user program the problem occurred.

  The compiler is supposed to do type inference well enough that 
  the declaration in
  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,
             (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
               (LET ((I 0) (G2554 LENGTH))
                 (DECLARE (TYPE REAL G2554) (TYPE REAL I))
                  (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
                  (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
                  (GO SB-LOOP::NEXT-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)).

    list. It seems to me that the "implementation specific environment
    hacking functions" found in pcl/walker.lisp are completely messed
    PCL and the munged environment object is passed to cmucl only
  SBCL uses essentially the same code, so if the environment hacking
  is screwed up, it affects us too.

  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.

  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):
    (CONCATENATE 'FOO #(1 2) '(3)) 
      => #<ARRAY-TYPE SIMPLE-ARRAY> 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:
    (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
  See also bug #46a./b., and discussion and patch sbcl-devel and
  cmucl-imp 2002-07

  crashes SBCL. In general tracing anything which is used in the 
  implementation of TRACE is likely to have the same problem.

  (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.


  ANSI says in one place that type declarations can be abbreviated even
  when the type name is not a symbol, e.g.
  and Pierre Mai.)

  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
  files and make it share the same new safe logic.

  Functions are assigned names based on the context in which they're
  defined. This is less than ideal for the functions which are
  used to implement CLOS methods. E.g. the output of 
  (DESCRIBE 'PRINT-OBJECT) lists functions like 
  It would be better if these functions' names always identified
  them as methods, and identified their generic functions and

  it would decrease efficiency more than is probably necessary. Perhaps
  using some sort of accept/reject method would be better.

  Internally the compiler sometimes evaluates
  (I stumbled across this when I added an
  (I haven't tried to investigate this bug enough to guess whether
  there might be any user-level symptoms.)

  Inconsistencies between derived and declared VALUES return types for
  DEFUN aren't checked very well. E.g. the logic which successfully
  catches problems like
    (defun foo (x)
      (declare (type integer x))
  fails to catch
    (defun bar (x)
  was that this case
    (defun bar (x)
  to be compatible with callers who expects a single value to be
  returned. That intent is probably not appropriate for modern ANSI
  Common Lisp, but fixing this might be complicated because of other
  divergences between auld-style and new-style handling of
  on cmucl-imp at some length sometime in 2000.)

  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

  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.
    A proper solution involves deciding whether it's really worth
  saving space by implementing structure slot accessors as closures.
  an EQUAL hash table mapping from types to compiled type tests, 
  and save the appropriate compiled type test as part of each lexical
  closure; or we could make the lexical closures be placeholders
  which overwrite their old definition as a lexical closure with
  a new compiled definition the first time that they're called.)
		  ;; a workaround for the problem, encouraging the
		  ;; inline expansion of the structure accessor, so
		  ;; that the compiler can optimize its type test
      ;; no problem, can just use the ordinary expansion

  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
  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.

  (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
	  an external symbol
	  in #<PACKAGE "SB-ALIEN">.
	Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
	  Macro arguments:  (#:whole-470 #:environment-471)
	  On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
	    Created: Monday, March 12, 2001 07:47:43 AM CST

  time trying to GC afterwards. Surely there's some more economical
  way to implement (ROOM T).

  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
    ;;; The compiler is flushing the argument type test, and the default
    ;;; case in the cond, so that calling with say a fixnum 0 causes a
    ;;; SIGBUS.
    (declaim (optimize (safety 2) (speed 3)))
    (defun tst (x)
      (declare (type (or string stream) x))
      (cond ((typep x 'string) 'string)
            ((typep x 'stream) 'stream)
  The symptom in sbcl- on OpenBSD is actually (TST 0)=>STREAM
  (not the SIGBUS reported in the comment) but that's broken too; 
  type declarations are supposed to be treated as assertions unless
  SAFETY 0, so we should be getting a TYPE-ERROR.

    (in-package :cl-user)
    ;;; The following invokes a compiler error.
    (declaim (optimize (speed 2) (debug 3)))
    (defun tst ()
      (flet ((m1 ()
               (unwind-protect nil)))
        (if (catch nil)
  The error message in sbcl- is
    internal error, failed AVER:

  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 
  expansion is used in a context where only one of those results
  is acceptable, e.g.
    (defun foo (x)
  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)
  appropriate type,
    (defun foo (x)

  more conspicuous. If you don't need performance from these functions,
  your pre-0.7.0 state of grace with

   not SPARC; dunno about Alpha.)


   uses 80-bit precision internally.

   non-ANSI behavior of treating the function return type inferred
   from the current function definition as a declaration of the
   calls FOO. 

   There was some sort of screwup in handling of
   (IF (NOT (IGNORE-ERRORS ..))). E.g.
	(defun foo1i ()
	  (if (not (ignore-errors
		     (make-pathname :host "foo"
                                    :directory "!bla"
                                    :name "bar")))
	      (print "ok")
	      (error "notunlessnot")))
   The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
   printing "ok", but instead it's going to the ERROR. This problem
   seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
   2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
   I reverted back to the old weird HANDLER-CASE code. However, I
   think the problem looks like a compiler bug in handling RETURN-FROM,
   so I left the MNA-patched code in HANDLER-CASE (suppressed with
   #+NIL) and I'd like to go back to see whether this really is
   a compiler bug before I delete this BUGS entry.

   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 
   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
   SBCL just does this weird broken "conforming" thing.

   The ANSI standard says, in the definition of the special operator
       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.
	    ;The parameters x and flag are accessible here.
	     (+ x
	        (fudge x)
	        (fudge (+ x 1)))))
   but actual specification quoted above says that the actual behavior
   is undefined.

	(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
     (#<FUNCTION {500A9EF9}>)
   Evidently Python thinks of the lambda as a code transformation so
   much that it forgets that it's also an object.

  The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
  specifies a precedence rule for name collisions between slot accessors of
  structure classes related by inheritance. As of 0.7.0, SBCL still 
  doesn't follow it.

  insufficient syntax checking in MACROLET:
   (defun foo (x)
     (macrolet ((defmacro bar (z) `(+ z z)))
       (bar x)))
  shouldn't compile without error (because of the extra DEFMACRO symbol).

  As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
  the CL:COMPILE function (which is based on the same %COMPILE 
  mechanism) get confused by 
(defun sxhash (x)
  (labels ((sxhash-number (x)
	     (etypecase x
	       (fixnum (sxhash x)) ; through DEFTRANSFORM
	       (integer (sb!bignum:sxhash-bignum x))
	       (single-float (sxhash x)) ; through DEFTRANSFORM
	       (double-float (sxhash x)) ; through DEFTRANSFORM
	       #!+long-float (long-float (error "stub: no LONG-FLOAT"))
	       (ratio (let ((result 127810327))
			(declare (type fixnum result))
			(mixf result (sxhash-number (numerator x)))
			(mixf result (sxhash-number (denominator x)))
	       (complex (let ((result 535698211))
			  (declare (type fixnum result))
			  (mixf result (sxhash-number (realpart x)))
			  (mixf result (sxhash-number (imagpart x)))
	   (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
	     (declare (type index depthoid))
	     (typecase x
		(if (plusp depthoid)
		    (mix (sxhash-recurse (car x) (1- depthoid))
			 (sxhash-recurse (cdr x) (1- depthoid)))
		(if (typep x 'structure-object)
		    (logxor 422371266
			    (sxhash ; through DEFTRANSFORM
			     (class-name (layout-class (%instance-layout x)))))
	       (symbol (sxhash x)) ; through DEFTRANSFORM
	       (number (sxhash-number x))
		(typecase x
		  (simple-string (sxhash x)) ; through DEFTRANSFORM
		  (string (%sxhash-substring x))
		  (bit-vector (let ((result 410823708))
				(declare (type fixnum result))
				(dotimes (i (min depthoid (length x)))
				  (mixf result (aref x i)))
		  (t (logxor 191020317 (sxhash (array-rank x))))))
		(logxor 72185131
			(sxhash (char-code x)))) ; through DEFTRANSFORM
	       (t 42))))
    (sxhash-recurse x)))
  complaining "function called with two arguments, but wants exactly
  one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
  since IIRC post-fork CMU CL has also had problems with &OPTIONAL
  arguments in FLET/LABELS: it might be an old Python bug which is 
  only exercised by the new arrangement of the SBCL compiler.)

  Ideally, uninterning a symbol would allow it, and its associated
  FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
  are lost. 

  (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
    (defmethod foo ((x integer))
    (defmethod foo :around ((x integer))
      (let ((x (1+ x)))
  Now (FOO 3) should return 3, but instead it returns 4.

  (reported by Alexey Dejneka sbcl-devel 2002-01-03)

  SUBTYPEP does not work well with redefined classes:
  * (defclass a () ())
  * (defclass b () ())
  * (subtypep 'b 'a)
  * (defclass b (a) ())
  * (subtypep 'b 'a)
  * (defclass b () ())
  ;;; And now...
  * (subtypep 'b 'a)

  This bug was fixed in sbcl- by invalidating the PCL wrapper
  class upon redefinition. Unfortunately, doing so causes bug #176 to
  appear.  Pending further investication, one or other of these bugs
  might be present at any given time.

  Pretty-printing nested backquotes doesn't work right, as 
  reported by Alexey Dejneka sbcl-devel 2002-01-13:
  * (lisp-implementation-version)

  (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
  %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
  of the naturalized string. We could probably port the patches
  from the cmucl-imp mailing list.

  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: 
    minute or two, the lisp process will eventually say: 
         %PRIMITIVE HALT called; the party is over. 
    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: 

  The system accepts DECLAIM in most places where DECLARE would be 
  it's fairly easy to mistype DECLAIM instead of DECLARE, and the
  meaning is rather different, and it's unlikely that the user

  COMPLEX implementation didn't deal with this, and hasn't been
  conformance problem, since seems hard to construct useful code
  where it matters.)

  Floating point errors are reported poorly. E.g. on x86 OpenBSD
  with sbcl-0.7.1, 
	* (expt 2.0 12777)
	No traps are enabled? How can this be?

  See also bugs #45.c and #183

  In sbcl- on x86, COMPILE-FILE on the file
    (in-package :cl-user)
    (defvar *thing*)
    (defvar *zoom*)
    (defstruct foo bar bletch)
    (defun %zeep ()
      (labels ((kidify1 (kid)
               (kid-frob (kid)
                 (if *thing*
                    (setf sweptm
              	           (m+ (frobnicate kid)
		    (kidify1 kid))))
      (declare (inline kid-frob))
      (map nil
  fails with
    debugger invoked on condition of type TYPE-ERROR:
  The location of this failure has moved around as various related

  (essentially the same problem as a CMU CL bug reported by Martin
  Cracauer on cmucl-imp 2002-02-19)
  There is a hole in structure slot type checking. Compiling and LOADing
    (declaim (optimize safety))
    (defstruct foo
      (bla 0 :type fixnum))
    (defun f ()
      (let ((foo (make-foo)))
        (setf (foo-bla foo) '(1 . 1))
        (format t "Is ~a of type ~a a cons? => ~a~%"
                (foo-bla foo)
                (type-of (foo-bla foo))
                (consp (foo-bla foo)))))
  should signal an error, but in sbcl- instead gives the output
    Is (1 . 1) of type CONS a cons? => NIL
  without signalling an error.


  When a function is called with too few arguments, causing the
  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)
    * (lisp-implementation-version)
    * (typep 10)
    0] (room)
    failed AVER: "(SAP= CURRENT END)"
  isn't too surprising since there are many differences in stack
  implementation and GC conservatism between the X86 and other ports.)

    (in-package :cl-user)
    (defstruct uustk)
    (defmethod permanentize ((uustk uustk))
      (flet ((frob (hash-table test-for-deletion)
             (obj-entry.stale? (oe)
               (destructuring-bind (key . datum) oe
                 (declare (type simple-vector key))
                 (deny0 (void? datum))
                 (some #'stale? key))))
        (declare (inline frob obj-entry.stale?))
        (frob (uustk.args-hash->obj-alist uustk)
        (frob (uustk.hash->memoized-objs-list uustk)
  in sbcl- causes an assertion failure, 
    failed AVER:
      (NOT (EQ B (COMPONENT-HEAD #)))))"

  In sbcl-, compiling the (illegal) code 
    (in-package :cl-user)
    (defmethod prove ((uustk uustk))
      (zap ((frob () nil))
  gives the (not terribly clear) error message
    ; caught ERROR:
    ; can't get template for (FROB NIL NIL)
  is giving an unclear error message.

  (reported by Dan Barlow on sbcl-devel 2002-05-10)
  In sbcl-, doing
    (defstruct foo bar baz)
    (compile nil (lambda (x) (or x (foo-baz x))))
  gives an error
    debugger invoked on condition of type SB-INT:BUG:
       full call to SB-KERNEL:%INSTANCE-REF
    This is probably a bug in SBCL itself. [...]
  Since this is a reasonable user error, it shouldn't be reported as 
  an SBCL bug. 

  sbcl's treatment of at least macro lambda lists is too permissive;
  e.g., in sbcl-
    (defmacro foo (&rest rest bar) `(,bar ,rest))
    (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT))
  whereas section 3.4.4 of the CLHS doesn't allow required parameters
  to come after the rest argument.

  The compiler sometimes tries to constant-fold expressions before
    (WHEN X

  reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel:
    Playing with McCLIM, I've received an error "Unbound variable WRAPPER
      (defun check-wrapper-validity (instance)
        (let* ((owrapper (wrapper-of instance)))
          (if (not (invalid-wrapper-p owrapper))
              (let* ((state (wrapper-state wrapper)) ; !!!
    I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP
    breaks with "NIL is not of type SB-KERNEL:LAYOUT".
  partial fix: The undefined variable WRAPPER resulted from an error
  in recent refactoring, as can be seen by comparing to the code in e.g. 
  sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-
  should bring the code back to its behavior as of sbcl-0.7.2, but
  that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of 
  input which triggers that bug is
    (dotimes (i 20)
      (let ((lastname (intern (format nil "C~D" (1- i))))
            (name (intern (format nil "C~D" i))))
      (eval `(defclass ,name
                 (,@(if (= i 0) nil (list lastname)))
      (eval `(defmethod initialize-instance :after ((x ,name) &rest any)
               (declare (ignore any))))))
    (defclass b () ())
    (defclass c0 (b) ())
    (make-instance 'c19)

  See also bug #140.

178: "AVER failure compiling confused THEs in FUNCALL"
  In sbcl-, compiling
    (defun bug178 (x)
      (funcall (the function (the standard-object x))))
    failed AVER:
  This variant compiles OK, though:
    (defun bug178alternative (x)
      (funcall (the nil x)))

181: "bad type specifier drops compiler into debugger"
    (in-package :cl-user)
    (defun bar (x)
      (declare (type 0 x))
      (cons x x))
    bad thing to be a type specifier: 0
  which seems fine, but also enters the debugger (instead of having
  the compiler handle the error, convert it into a COMPILER-ERROR, and
  continue compiling) which seems wrong.

183: "IEEE floating point issues"
  Even where floating point handling is being dealt with relatively
  accrued-exceptions and current-exceptions part of the fp control
  * (/ 1.0 0.0)

  debugger invoked on condition of type DIVISION-BY-ZERO:
    arithmetic error DIVISION-BY-ZERO signalled

          :FAST-MODE NIL)
  0] abort
          :FAST-MODE NIL)

185: "top-level forms at the REPL"
  * (locally (defstruct foo (a 0 :type fixnum)))
  gives an error:
  ; caught ERROR:
  ;   (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR))
  however, compiling and loading the same expression in a file works
  as expected.

187: "type inference confusion around DEFTRANSFORM time"
  hand-expanding the DEFTRANSFORM would change this, but it suggests
  the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
  invoked at a particular phase) is involved.
    (cl:in-package :sb-c)
    (eval-when (:compile-toplevel)
    (defknown %dvai (array index) 
      (values t t) 
      (foldable flushable))
    (deftransform %dvai ((array index)
                         (vector t)
                         :important t)
        (when (eq eltype *wild-type*)
        `(if (array-header-p array)
             (%wad array index nil)
             (values array index))))
    ;;; standin for %WITH-ARRAY-DATA
      (foldable flushable))
        (when (array-type-p atype)
           `(values (simple-array ,(type-specifier
                    index index index)))))
    ) ; EVAL-WHEN
    (defun %wad (array start end)
      (%with-array-data array start end))
    (cl:in-package :cl-user)
    (defun tcx (v i)
      (declare (type (vector t) v))
      ;; go away.) 
      (sb-c::%dvai v i))

  (In sbcl-, DEFTRANSFORM CONCATENATE was commented out until this
    (time (compile
           '(lambda ()
              (declare (optimize (safety 3)))
              (declare (optimize (compilation-speed 2)))
  		 134.552 seconds of real time
  		 133.35156 seconds of user run time
  		 0.03125 seconds of system run time
                   [Run times include 2.787 seconds GC run time.]
  		 0 page faults and
  		 246883368 bytes consed.
  thinking about type relationships involving types like
       (OR (INTEGER 576 576)
           (INTEGER 1192 1192)
           (INTEGER 2536 2536)
           (INTEGER 1816 1816)
           (INTEGER 2752 2752)
           (INTEGER 1600 1600)
           (INTEGER 2640 2640)
           (INTEGER 1808 1808)
           (INTEGER 1296 1296)

190: "PPC/Linux pipe? buffer? bug"
  only sporadically reproducible.

191: "Miscellaneous PCL deficiencies"
  a. DEFCLASS does not inform the compiler about generated
     functions. Compiling a file with
       (DEFUN A-CLASS-X (A)
         (WITH-SLOTS (A-CLASS-X) A
     results in a STYLE-WARNING:

     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
     won't get the corresponding STYLE-WARNING.
  c. the examples in CLHS (regarding generic function lambda

192: "Python treats free type declarations as promises."
     sbcl-devel 2002-08-97) patch:
       (defun trust-assertion (i)
         (dotimes (j i)
           (unless (< i 5)
             (print j))))

193: "unhelpful CLOS error reporting when the primary method is missing"
  In sbcl-0.7.7, when
    (defmethod foo :before ((x t)) (print x))
  is the only method defined on FOO, the error reporting when e.g.
    (foo 12)
  is relatively unhelpful:
    There is no primary method for the generic function
  with the offending argument nowhere visible in the backtrace. This 
  continues even if there *are* primary methods, just not for the 
  specified arg type, e.g. 
    (defmethod foo ((x character)) (print x))
    (defmethod foo ((x string)) (print x))
    (defmethod foo ((x pathname)) ...)
  In that case it could be very helpful to know what argument value is
  falling through the cracks of the defined primary methods, but the
  error message stays the same (even BACKTRACE doesn't tell you what the
  bad argument value is).

  fixed parts:
    a. In sbcl-, 
       it's difficult to write a regression test for it, because 
       still returns (1 2 3).
  still-broken parts:  
       tests for fixed-ness of part a.)
    d. At the REPL,
         (null (ignore-errors
           (let ((arg1 1)
           => T
      (FOO) => NIL.
    * Actually this entry is probably multiple bugs, as
	I don't think that placing these two bugs in one entry is
	a good idea: they have different explanations. The second
	for the result, it forgets about type assertion. The purpose
	of IDENTITY is to save the restricted continuation from
	inaccurate transformations.
    * Alexey Dejneka pointed out that
      works as it should. Also
      works as it should. Perhaps this is another case of VALUES type
      intersections behaving in non-useful ways?

195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL"
  In sbcl-, (THE REAL #(1 2 3)) signals a type error which
  prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)".
  REAL is unnecessarily confusing, especially since it relies on 
  internal implementation knowledge that even with SHORT-FLOAT
  and LONG-FLOAT left out of the union, this type is equal to REAL.
  So it'd be better just to say "This is not a REAL".

196: "confusing error message for unREAL second arg to ATAN"
  (fixed in sbcl-

    The # values reached 6 before the category was closed down.