On Thu, Aug 21, 2008 at 10:46 AM, Jean-Daniel Dupas <[EMAIL PROTECTED]> 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 PROTECTED]
_______________________________________________ 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]
