🚀 go-pugleaf

Christopher R. Volpe (volpe@bart.crd.ge.com) wrote:
: 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.

There is another advantage in having NULL to be defined as "(void*)0" in that
it allows the compiler to pick up the incorrect (in terms of programer
understanding) use of NULL in a non pointer context. Eg:
    the compiler can report an error when given

        func( NULL )

    if func() is prototyped as
    
        func( int )

    if NULL was defined as "0" then the compiler would not detect this.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom