{"id":54,"date":"2008-05-31T17:14:47","date_gmt":"2008-05-31T22:14:47","guid":{"rendered":"http:\/\/vgable.com\/blog\/2008\/05\/31\/messages-to-nowhere\/"},"modified":"2009-04-19T09:51:21","modified_gmt":"2009-04-19T14:51:21","slug":"messages-to-nowhere","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2008\/05\/31\/messages-to-nowhere\/","title":{"rendered":"Messages to Nowhere"},"content":{"rendered":"

If you send a message to (call a method of) an object that is nil<\/code> (NULL<\/code>) in Objective-C, nothing happens, and the result of the message is nil<\/code> (aka 0<\/code>, aka 0.0<\/code>, aka NO<\/code> aka false<\/code>). At least most of the time. There is an important exception if sizeof(return_type) > sizeof(void*)<\/code>; then the return-value is undefined<\/b> 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,<\/code> or long long<\/code>.<\/p>\n

The fully story:<\/a><\/p>\n

\nIn Objective-C, it is valid to send a message to a nil<\/code> object. The Objective-C runtime assumes that the return value of a message sent to a nil<\/code> object is nil<\/code>, as long as the message returns an object or any integer scalar of size less than or equal to sizeof(void*).<\/code>
\nOn Intel-based Macintosh computers, messages to a nil<\/code> object always return 0.0<\/code> for methods whose return type is float, double, long double, <\/code> or long long.<\/code> Methods whose return value is a struct<\/code>, as defined by the Mac OS X ABI Function Call Guide<\/a> to be returned in registers, will return 0.0<\/code> for every field in the data structure. Other struct<\/code> data types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.<\/p><\/blockquote>\n

I was recently bitten by this exceptional behavior. I was using an NSRange<\/code> struct<\/code> describing a substring; but the string was nil<\/code>, 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.<\/p>\n

Code running in the iPhone simulator will return all-zero stucts when messaging nil<\/code>, 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<\/strong>.<\/p>\n

A few simple guidelines can help you avoid my misfortune:<\/p>\n