On Thu, Aug 21, 2008 at 1:47 AM, Thomas Engelmeier <[EMAIL PROTECTED]> wrote: > > Am 21.08.2008 um 05:03 schrieb Michael Ash: > >>>> There was a common perception that NULL is not really the same as nil. >>>> But >>>> seems like in the end it really is (void*)0. >>> >>> They differ in type, not in value. >>> >>> "NULL" is (void *) 0. >>> "nil" is (id) 0. >>> "Nil" is (Class) 0. >> >> This is true conceptually but not as far as their actual definition. >> NULL can be either 0 or (void *)0. > > Let's be a little bit more precise, I'll try to paraphrase correctly from my > memory: > > a.) > (int) NULL is NOT required or guaranteed 0x0 by the standard. This is why > one should never use > if( anPtr == (void *) 0 ); > instead of > if( anPtr == NULL ); > On modern machines, it usually is.
This is not true. Those two expressions are identical as far as C is concerned, on any machine with a conforming C implementation (i.e. (void*)0 and NULL are both valid null pointer constants.) I think you are trying to say that the *representation* of a null pointer needn't necessarily be all-bits-zero (i.e. you won't always get a null pointer if you bzero/or memset it to zero). In that, you are correct, but that is orthogonal to the discussion here (and there is currently no C implementation with such null pointers that I know of). > b.) At least the C++ standard mandates for type conversion of an pointer to > an boolean, that e.g. ( !anPtr ) is equivalent to ( !(anPtr == NULL )). I believe you mean that (!anPtr) is equivalent to (anPtr == NULL), in which case, you are correct for C and C++. > I didn't read the C99 spec but I'm sure there is something similar specified. > > This implementation detail This is not an implementation detail, it is a guarantee of the standards, and is essential to the C and C++ languages. > does probably not matter on most platforms today > as even microcontrollers have AFAIK linear address spaces. The above is true on *any* C implementation, even those without a linear address space. > When I was writing my first C app on a DOS machine, there were segmented > addresses. That meant it could happen that > > ((somePtr + offset) - offset) == somePtr > > evaluated to false - (somePtr + offset) changed the segment, anotherPtr - > offset did not. Big debug surprise for poor little 68020 fanboy ;-) Indeed, but this is also a separate issue, even on DOS, (!anPtr) is equivalent to (anPtr == NULL). Unless somePtr is a pointer to an array or object that is at least (offset - 1) bytes in size, then ((somePtr + offset) - offset) causes undefined behavior on any platform (it just dosen't usually manifest on platforms with a linear address space) -- Clark S. Cox III [EMAIL PROTECTED] _______________________________________________ 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]
