🚀 go-pugleaf

In article <49cvna$ir7@nntp.Stanford.EDU>, becker@Xenon.Stanford.EDU (Denizen of the Deep) writes:
>>normally pointers to functions either.
>
>I disagree.  I understand that calling 0 a null pointer constant is
>just a special case.  My point is not to ask "why should (void *)0 fit
>in the type system?"  As you point out, the standard just declares it
>by fiat.  My point is to ask "Isn't this misleading?"
>
>Given that we're going to have a special case (using an integral
>constant expression equal to 0), the only reason I can see for
>also allowing (void *)0 is that the type (void *) in some way
>represents the notion of a "generic" pointer type, or a pointer
>type with minimal information.  But in fact, void * is NOT
>generic, since there is a whole class of pointer types with
>which it is not compatible.
>
>I guess what I'm saying is that I don't understand why the type
>void * should be given special consideration in this context.

It shouldn't. This special case is a hack that enables the Standard to conform
with the gazillions of existing implementations that #define NULL as 
"(void *)0", and user programs that do the same. It's about backward
compatibility.

There is also another advantage to allowing NULL to be defined as "(void *)0".
It helps some broken code to work correctly, despite being broken. If NULL had
to be defined as "0", then code which called unprototyped functions, which
expected a pointer argument, with "NULL" as an argument, would actually be
passing the integer zero (which might not have the same bit pattern as a
null pointer to whatever type). Having the cast built into the macro ensures
that a null pointer of some type is always passed. Of course, a null pointer
to void could have a different representation from a null pointer to int, so
this won't always save you.

--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com