Re: [Obj-C] if (self) vs. if (self != nil)
Re: [Obj-C] if (self) vs. if (self != nil)
- Subject: Re: [Obj-C] if (self) vs. if (self != nil)
- From: Kyle Sluder <email@hidden>
- Date: Sat, 25 Feb 2012 07:56:55 -0800
On Feb 25, 2012, at 7:45 AM, Scott Ribe <email@hidden> wrote:
> On Feb 25, 2012, at 8:38 AM, Kyle Sluder wrote:
>
>> Does Harbison & Steele say that pointers converted to integer have the value zero, or does it say that if(ptr) is identical to if(ptr != 0)?
>
> It explicitly states that null pointers converted to int are 0, and that other conversions are implementation-defined but round-trip conversions through a large-enough int type produce the original pointer.
Yeah, that's all kinds of wrong. As the standard also explicitly states, converting a pointer to integer is not guaranteed to result in a representation that fits in any size of integer, and it might be a trap representation. The conversion from integer to pointer is similarly implementation-defined. The only round-trip guaranteed by the standard is pointer-type to pointer-type, and then only if the pointer value is correctly aligned for the second pointee type, or the second pointer type is pointer-to-void.
> I have a suspicion that this is a normalization in behavior introduced in the standardization process--note that I still have K&R 2nd edition here, and as far as I can tell it simply does not specify what happens when a null pointer is converted to int.
K&R 2nd Ed. was updated for C89, I believe. But regardless, K&R is notoriously light on specifics like this. Which is great when you're teaching a language, but not nearly as great when you're implementing a compiler that intends to support most of the code in the modern world.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden