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)
-
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.
forever, even when it is uninterned and all other references to it
are lost.
-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
This is probably the same bug as 162
-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.
-
- As of 0.9.15.41 this seems to be due to ACC being inlined only once
- inside FOO, which results in the second call reusing the FUNCTIONAL
- resulting from the first -- which doesn't check the type.
-
237: "Environment arguments to type functions"
a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
UPGRADED-COMPLEX-PART-TYPE now have an optional environment
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
-
242: "WRITE-SEQUENCE suboptimality"
(observed from clx performance)
In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
conditionalization and OAOOMization: refactoring the common parts would
be good.
-354: XEPs in backtraces
- Under default compilation policy
- (defun test ()
- (throw :unknown t))
- (test)
- Has the XEP for TEST in the backtrace, not the TEST frame itself.
- (sparc and x86 at least)
-
- Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
- is true (instead there appear two TEST frames at least on ppc). The
- underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
- the tail-call for the XEP, since Python has by that time proved that
- the function can never return; same happens if the function holds an
- unconditional call to ERROR.
-
356: PCL corruption
(reported by Bruno Haible)
After the "layout depth conflict" error, the CLOS is left in a state where
(make-instance 'bar)
]
-357: defstruct inheritance of initforms
- (reported by Bruno Haible)
- When defstruct and defclass (with :metaclass structure-class) are mixed,
- 1. some slot initforms are ignored by the DEFSTRUCT generated constructor
- function, and
- 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably
- OK for initforms that were given in a DEFSTRUCT form, but for those
- given in a DEFCLASS form, I think it qualifies as a bug.)
- Test case:
- (defstruct structure02a
- slot1
- (slot2 t)
- (slot3 (floor pi)))
- (defclass structure02b (structure02a)
- ((slot4 :initform -44)
- (slot5)
- (slot6 :initform t)
- (slot7 :initform (floor (* pi pi)))
- (slot8 :initform 88))
- (:metaclass structure-class))
- (defstruct (structure02c (:include structure02b (slot8 -88)))
- slot9
- (slot10 t)
- (slot11 (floor (exp 3))))
- ;; 1. Form:
- (let ((a (make-structure02c)))
- (list (structure02c-slot4 a)
- (structure02c-slot5 a)
- (structure02c-slot6 a)
- (structure02c-slot7 a)))
- Expected: (-44 nil t 9)
- Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..
- SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..)
- ;; 2. Form:
- (let ((b (make-instance 'structure02c)))
- (list (structure02c-slot2 b)
- (structure02c-slot3 b)
- (structure02c-slot4 b)
- (structure02c-slot6 b)
- (structure02c-slot7 b)
- (structure02c-slot8 b)
- (structure02c-slot10 b)
- (structure02c-slot11 b)))
- Expected: (t 3 -44 t 9 -88 t 20)
- Got: (0 0 0 0 0 0 0 0)
-
359: wrong default value for ensure-generic-function's :generic-function-class argument
(reported by Bruno Haible)
ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says:
(FOO 1 2)
gives NO-APPLICABLE-METHOD rather than an argument count error.
-395: Unicode and streams
- One of the remaining problems in SBCL's Unicode support is the lack
- of generality in certain streams.
- a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT)
- to streams made from strings that aren't character strings with
- fill-pointers:
- (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char)))
- (format v "foo")
- v)
- should return a non-simple base string containing "foo" but
- instead errors.
-
- (reported on sbcl-help by "tichy")
-
396: block-compilation bug
(let ((x 1))
(dotimes (y 10)
projects / sbcl.git / blobdiff