[tz] [PATCH 1/3] Assume C89.

Paul_Koning at Dell.com Paul_Koning at Dell.com
Fri Oct 12 18:38:07 UTC 2012

Off into the deep weeds alert...

On Oct 12, 2012, at 1:20 PM, Todd C. Miller wrote:

> On Fri, 12 Oct 2012 17:09:15 -0000, Paul_Koning at Dell.com wrote:
>> Makes no difference; NULL is just a macro that translates to 0, sometimes wit
>> h a mostly-unnecessary cast to void*.
> Ah but it *does* matter on 64-bit systems where 0 and 0L are not
> the same.  In this case, the prototype for select() will result in
> the 0 being coerced correctly, but using NULL improves readability
> since the parameter is a pointer and not an integer.

This is a very popular confusion.  In a situation where the type you're dealing with is "pointer" -- for example, in an argument list of a function that has a prototype -- the token 0 means "the null pointer".  It does not mean the integer zero.  Its length is that of a pointer, which may be different from that of the plain integer 0.  But you never write 0L for a null pointer, only 0.

Also, it doesn't matter if a null pointer actually has the same encoding as an integer zero.  

This is also why in varyadic functions when you need to pass a null pointer you have to say (void*)0.  That tells the compiler to supply the encoding of a null pointer -- with whatever length and bit pattern that implies.  If you're supposed to pass a null pointer to a varyadic function (like execl) then (void*)0 is correct and neither 0 nor 0L are correct.

But for calls to select, when there is a prototype, NULL and 0 are both valid and are equivalent with any conforming ANSI C compiler.  So is (anytype *)0, or for that matter (anytype *)NULL.


More information about the tz mailing list