[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.
paul
More information about the tz
mailing list