[armedbear-devel] Fwd: Re: Questions about r14452 (Fix cl-cont)

[Erik Huelsmann]

sent from my phone
---------- Forwarded message ----------
From: ehuels at gmail.com
Date: Apr 2, 2013 7:51 PM
Subject: Re: Questions about r14452 (Fix cl-cont)
To: Rudolf Schlatte <rudi at constantly.at>
Cc:

Hi Rudi,

Basically the expectation we violated was the fact that %set-lambda-name
didn't want to take a funcallable instance as its function argument. The
commit changed that and used the first slot  of the funcallable  instance
class layout (called NAME) to store the name. I guess we forget to finalize
the class somewhere, so the spots don't appear?

Bye,

Erik.

sent from my phone
On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi at constantly.at> wrote:

Hi,

I suspect that the changes in commit r14452 only work by accident.

The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs
FuncallableStandardObject are no problem, since the latter simply isn't
used anywhere.  But the new methods getName() and setName() assume that a)
the FuncallableStandardObject instance has at least one slot, and b) that
slot holds a name.  Since
    (class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact
generic functions.

Amusingly,
    (function-lambda-expression (make-instance
'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value
#<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even
though
    (typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.

Could I have a recipe for triggering the bug?  I'd like to see how cl-cont
uses funcallable-standard-objects, and what expectations we violate.  I
believe I can fix this properly.

Cheers,

Rudi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130402/e1a723c9/attachment.html>