On Wed, Sep 10, 2008 at 1:03 PM, Michael Ash <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
