Re: NSInvocation
Re: NSInvocation
- Subject: Re: NSInvocation
- From: "Michael Ash" <email@hidden>
- Date: Wed, 10 Sep 2008 13:44:54 -0400
On Wed, Sep 10, 2008 at 1:03 PM, Michael Ash <email@hidden> wrote:
> And in case anybody is wondering how the heck this works when the
> method isn't implemented, it's actually pretty straightforward. Cocoa
> has an internal function which builds an NSInvocation from the method
> arguments, then calls -forwardInvocation: with that newly-built
> object. In the case of an unimplemented selector, -methodForSelector:
> essentially just returns a pointer to that special function. So all
> unimplemented selectors will always return the same function. (Or,
> probably, it will return one of a couple of different functions
> depending on the calling convention required for the method's return
> type.)
Well, wouldn't you know it, I'm wrong.
That parenthetical at the end of my paragraph above is key.
-methodForSelector: needs to return different trampolines depending on
the return type (because of different calling conventions) in order to
function properly. But it *doesn't*.
If you use -methodForSelector: to call a forwarded method with the
standard int/pointer/void calling convention, everything works fine.
But if you use it to call a method which returns a struct, then it
crashes and burns. It doesn't even throw an exception, it just
segfaults.
I've filed this as a bug as rdar://6210060. It really should work, but
it doesn't.
In the meantime, for struct return methods, either make absolutely
sure that your target implements it and doesn't forward it, or use
another technique such as calling objc_msgSend_stret.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden