On Aug 20, 2008, at 4:57 PM, Michael Ash wrote:
(Now, they don't have to be. As I recall, NULL can just be a plain integer 0 as well. But they do have to be equivalent, and it just so happens that they are identical even though they don't need to be.)
Let me share a cautionary tale. At one point I was converting some Objective C code to be 64-bit ready, but for some reason it kept failing, in very strange ways. After much hunting, the problem turned out to be due to some old cross-platform code that the Objective C code linked against and imported headers from. I finally discovered that one of the headers in this old cross-platform code had defined NULL to be 0, just a plain integer 0, rather than (void *)0.
Well, after all, zero is zero, how much difference can it make? Quite a bit, as it turns out, since in 64-bit one of them is four bytes of zero, and the other is eight bytes of zero. If you're just comparing against NULL, it doesn't matter, but if you're using it in something where size counts--say, a list of vararg arguments--then it matters a lot. It's not easy to debug, though, because who would think that you need to distinguish one NULL from another?
I made sure that the definition of NULL from those cross-platform headers never made it in to my Objective C code, and all was fine. In Cocoa, NULL, nil, and Nil all should and must be pointer-sized zeros. By convention NULL is used for arbitrary pointers, nil for objects, and Nil for classes, and you should stick to that convention, even though it isn't strictly required by the language.
Douglas Davidson _______________________________________________ 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]
