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