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 11:40:53 -0700
On Thu, Aug 21, 2008 at 10:46 AM, Jean-Daniel Dupas
<email@hidden> wrote:
>
> Le 21 août 08 à 19:06, Scott Ribe a écrit :
>
>> Wow, don't check the list for a few days and look what happens!
>>
>>> After all, that's why nil (and Nil) exist at all,
>>> rather than just reusing NULL.
>>
>> Actually nil exists at all because Objective-C was created *before* NULL
>> was
>> in such standard use! (It may have always been part of stdio.h, don't
>> recall
>> for sure, but there definitely was no stddef.h.) Way back when, everybody
>> defined their own macro, and some libraries even called it NIL or nil or
>> null instead of NULL. (Others simply used 0.)
>>
>>> 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.
>>
>> Yes, that is allowed. In fact, Stroustrup suggests that it is preferred
>> for
>> C++, because stricter type checking makes ((void*)0) much less useful...
>> GCC
>> (actually g++) gets around this by providing __null, which is a magic
>> token
>> that gets special treatment from the compiler. If you look at stddef.h
>> and/or _types.h, you'll see a special case for __GNUG__ (GNU C++) that
>> defines NULL to be __null.
>>
>>> It is a little known fact that when passing NULL (and by extension nil
>>> or Nil) as a parameter to a vararg function, you *must* cast it to the
>>> appropriate pointer type to guarantee correct behavior.
>>
>> 2 reasons: 1) integer & pointer sizes may not be the same, this is the
>> common case, and is cured by defining NULL as ((void*)0) and nil as
>> ((id)0)
>> instead of just 0, and is why Apple gets away with this usage, and I
>> suspect
>> the g++ magic __null takes care of this as well; 2) The standard actually
>> allows different types of pointers to have different sizes, which I think
>> is
>> very rare, and certainly not the case on any architectures on which Cocoa
>> does (or ever did) run--or any that I've ever worked with.
>>
>>> Boolean negating a
>>> pointer is a hack that by happy coincidence works.
>>
>> No it is not; it is an explicitly designed and required feature of the
>> language.
>>
>>> a.)
>>> (int) NULL is NOT required or guaranteed 0x0 by the standard.
>>
>> Yes, it is.
>>
>>> Obviously I overlooked that the standard guarantees the
>>> conversion NULL => int results in 0 and vice versa.
>>
>> OK, close but not quite. The standard says that NULL is 0, and that all
>> pointer <-> int conversions take care of mapping the machine's null
>> address
>> to the integer 0, if necessary.
>
>
> Could you tell me which part of the standard states that NULL is 0.
NULL *can* be 0, it isn't *necessarily* 0
> I don't
> managed to find it. The only relevant part I found about NULL is the section
> 7.17.
>
> Common definitions <stddef.h> :
>
> NULL
> which expands to an implementation-defined null pointer constant;
... and 0 is a valid null pointer constant. From 6.3.2.3:
3 An integer constant expression with the value 0, or such an
expression cast to type
void *, is called a null pointer constant. If a null pointer constant
is converted to a
pointer type, the resulting pointer, called a null pointer, is
guaranteed to compare unequal
to a pointer to any object or function.
--
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