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 PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice _______________________________________________ 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]
