If you send a message to (call a method of) an object that is
NULL) in Objective-C, nothing happens, and the result of the message is
false). At least most of the time. There is an important exception if
sizeof(return_type) > sizeof(void*); then the return-value is undefined under PowerPC/iPhone, and thus all Macs for the next several years. So watch out if you are using a return value that is a
struct, double, long double, or
In Objective-C, it is valid to send a message to a
nilobject. The Objective-C runtime assumes that the return value of a message sent to a
nil, as long as the message returns an object or any integer scalar of size less than or equal to
On Intel-based Macintosh computers, messages to a
nilobject always return
0.0for methods whose return type is
float, double, long double,or
long long.Methods whose return value is a
struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, will return
0.0for every field in the data structure. Other
structdata types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.
I was recently bitten by this exceptional behavior. I was using an
struct describing a substring; but the string was
nil, so the substring was garbage. But only on a PPC machine! Even running under Rosetta wouldn’t have reproduced the bug on my MacBook Pro.Undefined values can be a hard bug to detect, because they may be reasonable values when tests are run.
Code running in the iPhone simulator will return all-zero stucts when messaging
nil, but the same code running on an actual device will return undefined structs. Be aware that testing in the simulator isn’t enough to catch these bugs.
A few simple guidelines can help you avoid my misfortune:
- Be especially careful using of any objective-C method that returns a
- Don’t write methods that return a
long long. Return an object instead of a
floatinstead of a
long long. If you must return a dangerous data type, then see if you can avoid it. There really isn’t a good reason to return a
struct, except for efficiency. And when micro-optimizations like that matter, it makes more sense to write that procedure in straight-C, which avoids the overhead of Objective-C message-passing, and solves the undefined-return-value problem.
- But if you absolutely must return a dangerous data type, then return it in a parameter.
- (double) crazyMath;
- (void) crazyMathResult:(double*)result;.
I love Objective-C’s “nil messaging” behavior, even though it is rough around the edges. It’s usefulness is beyond the scope of this article, but it can simplify your code if you don’t return a data-type that is larger then
sizeof(void*). With time, when the intel-style return behavior can be universally relied on, things will be even better.