Re: !foo vs foo == nil
Re: !foo vs foo == nil
- Subject: Re: !foo vs foo == nil
- From: Scott Ribe <email@hidden>
- Date: Thu, 21 Aug 2008 11:06:17 -0600
- Thread-topic: !foo vs foo == nil
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.
--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 722-0567 voice
_______________________________________________
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