msf@ames-prandtl.arpa (04/28/87)
As has been pointed out, NULL is replaced by the preprocessor as 0 before ccom ever sees it. A great deal of talk back and forth has now gone on concerning the `magic' properties of integer 0 with reference to pointers. I am not sure if this is a valid point, but.... The compiler (ccom) doesn't see integer 0, it sees character zero (okay, so it may be tokenized). In its myriad of default typcasting rules, wouldn't any C compiler that conforms to K&R have to typecast the symbol 0 to the appropriate pointer? And, to conform to the special properties of the symbol 0 in the source code (I didn't say anything about what the object code bit pattern is), wouldn't that pointer have to be whatever the specific machine architecture uses for a non valid pointer (such as bit 0's on the VAX, all 0xf's on some arbitrary QMC, etc)? If the compiler doesn't typecast 0 this way, it is not (it seems) conforming to the current (K&R) definition of C, not conforming to the future (ANSI) definition of C, and therefore, not C. I am not talking about the addition of features (void, enum, volatile), but the breaking of an integral part of the language specification. If I'm mistaken in paragraph 2, let me know. If you disagree with paragraph 3 but not with 2, send flame to /dev/null. mike