Re: !foo vs foo == nil
Re: !foo vs foo == nil
- Subject: Re: !foo vs foo == nil
- From: "Clark Cox" <email@hidden>
- Date: Thu, 21 Aug 2008 07:42:21 -0700
On Thu, Aug 21, 2008 at 1:47 AM, Thomas Engelmeier
<email@hidden> 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@hidden
_______________________________________________
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