Header problems

[Roberto Shironoshita]

In article <3351 at chinet.UUCP> dag at chinet.UUCP (Daniel A. Glasser) writes:
>In article <7412 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>The implementor should put something like the following in each header:
>>	#define NULL 0
>
>Your use of NULL === 0 promotes unportable code, and is considered to be
>bad programming style in a world where portability across multiple machine
>architectures (ie, PDP-11, VAX-11, M680x0, I80x86 and Z800x) is required
>for commercial reasons.

K&R says, on page 97 (I think it is the 22nd printing of the 1978
edition),

	"C guarantees that no pointer that validly points at data will
	 contain zero ..."

Since from what Doug says NULL remains in the language because of its
widespread use in K&R-conforming programs, then his #define is valid.

>On machines were sizeof int != sizeof(void *), the above definition will
>not work on older style function calls (without prototypes) or in var-arg
>situations.  Requiring sizeof int == sizeof(void *) is not a viable
>solution.  A better way to do it, in each place you want to define NULL,
>is:
>
>	#ifndef	NULL
>	#define	NULL	((void *)0)
>	#endif

First I don't see where Doug requires that sizeof int == sizeof(void *).
Second, your #define might break a lot of good code, which is what
X3J11 tries to avoid by leaving NULL (as defined in K&R) in the
standard.

>What the C language guarentees is not that 0===NULL, but that a constant 0
>can be assigned/compared to a pointer without warning or error regardless
>of pointer representation and compare as equal to the NULL pointer.

You seem to forget that what the preprocessor does is to replace every
occurrence of NULL (except inside strings and character literals) with
whatever it was #define'd.  So, the lexical analyzer doesn't see the
lexeme `NULL'; it sees the constant 0.  Hence, to the programmer, if
there is a `#define NULL 0' anywhere in his code, NULL === 0.  Your
point is valid, in that the above doesn't necessarily mean that
NULL === (void *)0

>In cases where the compiler is unable to determine if an int or type *
>is being passed, 0 is passed as an int.  The use of the name NULL in the
>preprocessor does not affect this.

True.  Which is why a portability-conscious programmer should use
explicit type casts in his function calls.

                                  Roberto Shironoshita
-------------------------------------------------------------------------
1- The University doesn't know I exist.   | Internet:
2- Of course I may be wrong.              |   shirono at grasp.cis.upenn.edu