Must a NULL pointer be a 0 bit pattern?

Sam Kendall kendall at wjh12.UUCP
Tue Oct 16 02:39:04 AEST 1984


> ...  There is no committment to the bit pattern of a 0 pointer in C.
> As such, I see no reason not to map a 0 pointer onto bit pattern you
> want, as long as 1) it's distinct from *all* bit patterns for
> legitimate pointers in C, ...  and 2) it fits in the same number of
> bits as any other pointer.
> 
> 	Guy Harris

   This is a very interesting point.  I claim that for K&R C, a null
pointer, and a floating point zero as well, MUST be the zero bit
pattern.  (The fact that some implementations cannot conform to this
means that the language must change; ANSI C deals with this problem, as
explained below.)

   The "proof" goes as follows: consider this external declaration:

	union {
		char *	p_member;
		double	f_member;
		char	c_member[COVERS_P_AND_F];
	} implicitly_initialized_to_zero;

It seems to me that K&R guarantees that, when the program begins
execution, p_member, f_member and c_member are guaranteed to be
zero simultaneously, and the only way to do it is to make them all a
zero bit pattern.  I don't have my manual with me--can anyone try to
poke holes in this?  It may be that the K&R wording isn't rigorous
enough, and that my proof "falls to the ground".

   ANSI C deals with this by giving a rule for explicit initialization
of unions: the first member is the one that is initialized.  Implicit
initialization can use the same rule, meaning that in the above example,
only p_member would be guaranteed to start out as a zero (null) value.

	Sam Kendall	  {allegra,ihnp4,ima,amd}!wjh12!kendall
	Delft Consulting Corp.	    decvax!genrad!wjh12!kendall



More information about the Comp.lang.c mailing list