Comments on: Nil

By: Jack Waugh

Jack Waugh — Fri, 24 Apr 2009 18:02:16 +0000

You guys (here and at http://unixjunkie.blogspot.com/2006/02/messaging-nil-in-objective-c.html ) talk as though there were no language standard for Objective-C. I don’t care because I don’t swim in your world, but it’s a sad state when you decide how to program by looking at an implementation of the language.

By: ridiculous_fish

ridiculous_fish — Wed, 21 Jun 2006 19:56:26 +0000

Key phrase there is “to be returned in registers.” Small structs that are returned in registers are zeroed; other structs are not and cannot be.

By: rpd

rpd — Wed, 21 Jun 2006 07:11:26 +0000

Well, based on the revised universal binary guidelines, it looks like everything including floats and structs returns zero:

http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/chapter_5_section_20.html

On Intel-based Macintosh computers, messages to a nil object always return 0.0 for 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.0 for every field in the data structure. Other struct data types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.

By: Matt Gallagher

Matt Gallagher — Thu, 05 Jan 2006 00:19:14 +0000

Trying to give other developers heart-attacks, Rob?

Fortunately: http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/chapter_5_section_20.html

which says:

Do not rely on the nil-messaging feature for methods whose return types are float, double, long long, or struct. On an Intel-based Macintosh computer, the return value is undefined for Objective-C messages sent to nil for these return types.

Phew. No hideous debug/audit required.

P.S. Great blog, thanks ridiculous_fish!

By: Rob Winchester

Rob Winchester — Sun, 19 Jun 2005 15:08:17 +0000

At WWDC one of the small (critical) tidbits they mentioned is that, on INTEL, you can no longer send messages to NIL… it will crash. Just a minor change there…

By: ridiculous_fish

ridiculous_fish — Tue, 07 Jun 2005 19:09:14 +0000

Thanks, Daniel. I had noticed that Monday – the PDF document is incorrect and should be fixed.

By: Daniel Ericsson

Daniel Ericsson — Mon, 06 Jun 2005 20:30:37 +0000

“On a Macintosh using an Intel microprocessor, Objective-C messages sent to nil return garbage for return values that are typed as float or double. On a Macintosh using a PowerPC microprocessor these messages return 0.0.”

Page 46.

http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf

By: Wim L

Wim L — Wed, 01 Jun 2005 20:08:00 +0000

Ages ago, IIRC, it was *documented* behavior that [nil blah...] was OK and would return nil if the method returned an id (or other object pointer). And of course, on machines where pointers and ints are register-compatible it works for ints as well. As you point out it’s easy to get sloppy and use it for a float or a struct and end up with hard-to-reproduce behaviorâ€¦

By: ridiculous_fish

ridiculous_fish — Wed, 01 Jun 2005 02:11:48 +0000

> Now â€” how bad would it be (from a performance standpoint) to move 0 into fp1 when you go
> down that path for sending a message to nil, thus eliminating a class of bugs. And in the case of
> struct returns, how bad would it be to fill the return struct with all 0â€™s in the case of sending to nil?

Moving 0 into fp1, to make float and double returns 0, would be very cheap. And while you’re at it, moving 0 into r4, to make long long returns 0, would be even cheaper. But doing this with structs would probably require substantial runtime changes, since the objc_msgSend_stret() function doesn’t know how big the struct return must be.

> In my opinion, it would not result in any noticable performance penalty (Iâ€™m assuming that
> messages passed to nil are the exception, not the rule), and could result in increased stability
> of apps running on this platform.

I agree with you, and I’ve asked this before. The answer I was given was that Apple doesn’t want to “special case” floats, doubles, and long longs since there’s not a ready solution for the general case.

You can see the conversation I had on Usenet.

By: Ian Ameline

Ian Ameline — Wed, 01 Jun 2005 01:58:13 +0000

Awesome blog — I’ll definitely be following it.

I’ve recently switched my primary development machine to be my mac, and It’s so much nicer.

Now — how bad would it be (from a performance standpoint) to move 0 into fp1 when you go down that path for sending a message to nil, thus eliminating a class of bugs. And in the case of struct returns, how bad would it be to fill the return struct with all 0’s in the case of sending to nil?

In my opinion, it would not result in any noticable performance penalty (I’m assuming that messages passed to nil are the exception, not the rule), and could result in increased stability of apps running on this platform.

What do you think?

Regards,
Ian Ameline,
Software Architect,
Alias Sketchbook Pro.