Comments on: Abusing Objective C With Class http://www.red-sweater.com/blog/320/abusing-objective-c-with-class Mac & Technology Writings by Daniel Jalkut Fri, 21 Nov 2008 07:03:41 +0000 http://wordpress.org/?v=2.6 By: Simon http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-84985 Simon Tue, 17 Apr 2007 22:10:33 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-84985 I've spent far more hours than I want to think about debugging stack corruption resulting from incorrect casts of function pointers and pointers-to-members. I'm currently porting Win32/MFC code (in my Windows-bound day job) from Visual C++ 6.0 to Visual Studio 2005. This problem is particularly insidious with MFC's message map macros of old which are full of yummy (and decidedly dodgy) casting. Making assumptions about function prototypes, calling conventions, return types at the C level is always a bad idea. Apple provides a solution with NSInvocation and it even lets you check the size of the return type against your expectations, so I'd prefer to go with that, even if I have to type a few more lines to buy that extra safety... I’ve spent far more hours than I want to think about debugging stack corruption resulting from incorrect casts of function pointers and pointers-to-members.

I’m currently porting Win32/MFC code (in my Windows-bound day job) from Visual C++ 6.0 to Visual Studio 2005. This problem is particularly insidious with MFC’s message map macros of old which are full of yummy (and decidedly dodgy) casting.

Making assumptions about function prototypes, calling conventions, return types at the C level is always a bad idea.

Apple provides a solution with NSInvocation and it even lets you check the size of the return type against your expectations, so I’d prefer to go with that, even if I have to type a few more lines to buy that extra safety…

]]> By: Shawn Erickson http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83745 Shawn Erickson Sat, 14 Apr 2007 17:17:19 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83745 Quick example that uses NSInvocation that supports an arbitrary selector to be used... <a href="http://homepage.mac.com/shawnce/ftsw/DynamicSelectorExample.m" rel="nofollow">DynamicSelectorExample.m</a> Note many optimizations could be made (cache the invocation object, etc.). Quick example that uses NSInvocation that supports an arbitrary selector to be used… DynamicSelectorExample.m

Note many optimizations could be made (cache the invocation object, etc.).

]]> By: Jürgen Schweizer http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83712 Jürgen Schweizer Sat, 14 Apr 2007 15:40:59 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83712 I agree with the overkill assessment in the case when all of the code is written by the same author. But I was actually thinking of a framework developer. I believe the dynamic approach you outlined above makes the most sense in frameworks where the actual application is not known at the time of development. And if you go with an informal protocol there is always a slight chance of misuse :). I agree with the overkill assessment in the case when all of the code is written by the same author. But I was actually thinking of a framework developer. I believe the dynamic approach you outlined above makes the most sense in frameworks where the actual application is not known at the time of development. And if you go with an informal protocol there is always a slight chance of misuse :).

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83703 Daniel Jalkut Sat, 14 Apr 2007 15:19:45 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83703 Jürgen - you're not wrong - my code doesn't check. But I think this is a kind of check that can be implemented at the discretion of the coder. Especially if the delegate sender and receiver are both written by the same coder, who is highly unlikely to ever flagrantly return a non-BOOL from a BOOL-returning delegate method :) Checking the type of the object seems like overkill to me in many cases. Jürgen - you’re not wrong - my code doesn’t check. But I think this is a kind of check that can be implemented at the discretion of the coder. Especially if the delegate sender and receiver are both written by the same coder, who is highly unlikely to ever flagrantly return a non-BOOL from a BOOL-returning delegate method :)

Checking the type of the object seems like overkill to me in many cases.

]]> By: Jürgen Schweizer http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83680 Jürgen Schweizer Sat, 14 Apr 2007 13:53:39 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83680 Daniel, please correct me if I am wrong, but your code does not seem to check, whether the delegate actually returns a BOOL. As an alternative, I suggest to let the delegate return an NSNumber. This way you will be able to dynamically check (-[NSObject isKindOfClass:]) whether you actually get an object of the correct class. Daniel, please correct me if I am wrong, but your code does not seem to check, whether the delegate actually returns a BOOL. As an alternative, I suggest to let the delegate return an NSNumber. This way you will be able to dynamically check (-[NSObject isKindOfClass:]) whether you actually get an object of the correct class.

]]> By: cjwl http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83285 cjwl Fri, 13 Apr 2007 14:01:00 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83285 I must have been sleeping when performSelector: broke for this situation, thanks for the post. I would avoid objc_msgSend though and to use your example: [Ed. Note: Code sample cut for formatting and brevity:] <code> BOOL (*MyMagicSender)(id, SEL, id, id)=(BOOL (*)(id, SEL, id, id))[mDelegate methodForSelector:delSelector]; if(MyMagicSender!=NULL){ shouldBrew = MyMagicSender(mDelegate, delSelector, self, [brewTimer fireDate]); } </code> If I wanted forwarding to work I'd go with NSInvocation's. I must have been sleeping when performSelector: broke for this situation, thanks for the post. I would avoid objc_msgSend though and to use your example:

[Ed. Note: Code sample cut for formatting and brevity:]

BOOL (*MyMagicSender)(id, SEL, id, id)=(BOOL (*)(id, SEL, id, id))[mDelegate methodForSelector:delSelector];

if(MyMagicSender!=NULL){
shouldBrew = MyMagicSender(mDelegate, delSelector, self, [brewTimer fireDate]);
}

If I wanted forwarding to work I’d go with NSInvocation’s.

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83281 Daniel Jalkut Fri, 13 Apr 2007 13:41:22 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83281 Eric: As usual, I suffer from "in one ear, out the other" syndrome until the day I actually need it :) The documentation you refer to is both good and concise. Nice work! Todd: the category method is probably a good idea, or at least an instance method encapsulating the "ask delegate for answer." But in any case the example I pasted here is both contrived and poorly documented - only intended to be a bare summary of how you might achieve a goal, given a requirement. Eric: As usual, I suffer from “in one ear, out the other” syndrome until the day I actually need it :) The documentation you refer to is both good and concise. Nice work!

Todd: the category method is probably a good idea, or at least an instance method encapsulating the “ask delegate for answer.” But in any case the example I pasted here is both contrived and poorly documented - only intended to be a bare summary of how you might achieve a goal, given a requirement.

]]> By: Todd Ransom http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83263 Todd Ransom Fri, 13 Apr 2007 13:14:07 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83263 I would avoid using this solution if at all possible because it is not obvious what that line of code does at a glance. A year or three from now when you or a colleague go back to look at this method, will you know the purpose of that line? Sure, you can add comments to it, but I would much rather create a category and implement -(BOOL)performBoolSelector:withObject:withObject: as Lucas suggests, because it looks and feels like Cocoa code instead of some gcc appeasement voodoo. .02, Todd I would avoid using this solution if at all possible because it is not obvious what that line of code does at a glance. A year or three from now when you or a colleague go back to look at this method, will you know the purpose of that line? Sure, you can add comments to it, but I would much rather create a category and implement -(BOOL)performBoolSelector:withObject:withObject: as Lucas suggests, because it looks and feels like Cocoa code instead of some gcc appeasement voodoo.

.02,
Todd

]]> By: Viuto http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83227 Viuto Fri, 13 Apr 2007 11:12:44 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83227 ... and sometimes you may also need to use gcc's -mstackrealign flag to avoid Intel x86 issues ... http://0xced.blogspot.com/2006/06/using-gnu-lightning-on-intel-mac.html … and sometimes you may also need to use gcc’s -mstackrealign flag to avoid Intel x86 issues …

http://0xced.blogspot.com/2006/06/using-gnu-lightning-on-intel-mac.html

]]> By: Eric Albert http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83187 Eric Albert Fri, 13 Apr 2007 08:15:55 +0000 http://www.red-sweater.com/blog/320/abusing-objective-c-with-class#comment-83187 A couple points here.... First, as with most differences between PowerPC and Intel Macs, this is covered in the Universal Binary Programming Guidelines (and has been since the Intel announcement). See <a href="http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/chapter_5_section_23.html" rel="nofollow">Objective-C Runtime: Sending Messages</a>, which happens to include this specific example. I helped write this section and made sure it got included in the document, so I take a little bit of pride in it. :) Second, Jonathan Johnson's comment about why this behaves differently on the two architectures is close but not quite right. The C99 'bool' type is a different size on PowerPC and Intel -- four bytes on PowerPC and one byte on Intel -- but the Objective-C BOOL type is the same size on both. You can see this in objc.h, where BOOL is typedef'd to a signed char. Why, then, does this sometimes behave differently on PowerPC and Intel? On PowerPC, the fastest way for the callee to write a one-byte value to the return register (r3) is to fill the entire register, so the compiler always ends up setting the four bytes in r3 to 0x0 or 0x1. If the caller thinks all four bytes were written, the result is the same. On Intel, the fastest way for the callee to write a one-byte value to EAX is sometimes to write the full register, as on PowerPC. Those cases behave the same they do on PowerPC. But sometimes the compiler decides to use one of the instructions which writes to AX (the low two bytes) or AL (the low byte) instead. From the compiler's perspective that's legal because it's writing out the return value for a function which is declared to return a single byte...but a caller which think it's getting four bytes back and reads those four bytes will end up seeing garbage in the high two or three bytes. That's when you realize you need a function pointer, since the function pointer tells the compiler that it's calling a function which is only guaranteed to set one byte in the return value. A couple points here….

First, as with most differences between PowerPC and Intel Macs, this is covered in the Universal Binary Programming Guidelines (and has been since the Intel announcement). See Objective-C Runtime: Sending Messages, which happens to include this specific example. I helped write this section and made sure it got included in the document, so I take a little bit of pride in it. :)

Second, Jonathan Johnson’s comment about why this behaves differently on the two architectures is close but not quite right. The C99 ‘bool’ type is a different size on PowerPC and Intel — four bytes on PowerPC and one byte on Intel — but the Objective-C BOOL type is the same size on both. You can see this in objc.h, where BOOL is typedef’d to a signed char.

Why, then, does this sometimes behave differently on PowerPC and Intel? On PowerPC, the fastest way for the callee to write a one-byte value to the return register (r3) is to fill the entire register, so the compiler always ends up setting the four bytes in r3 to 0×0 or 0×1. If the caller thinks all four bytes were written, the result is the same. On Intel, the fastest way for the callee to write a one-byte value to EAX is sometimes to write the full register, as on PowerPC. Those cases behave the same they do on PowerPC. But sometimes the compiler decides to use one of the instructions which writes to AX (the low two bytes) or AL (the low byte) instead. From the compiler’s perspective that’s legal because it’s writing out the return value for a function which is declared to return a single byte…but a caller which think it’s getting four bytes back and reads those four bytes will end up seeing garbage in the high two or three bytes. That’s when you realize you need a function pointer, since the function pointer tells the compiler that it’s calling a function which is only guaranteed to set one byte in the return value.

]]>