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@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