Re: !foo vs foo == nil
Re: !foo vs foo == nil
- Subject: Re: !foo vs foo == nil
- From: Jean-Daniel Dupas <email@hidden>
- Date: Thu, 21 Aug 2008 19:46:00 +0200
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. 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;
_______________________________________________
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