how has C bitten you? (Really,
Peter Curran
peterc at ecr2.UUCP
Wed Sep 11 22:04:46 AEST 1985
Although the topic of Null pointers has been beaten to death many times,
there is one point that I have never seen discussed.
External variables are to be initialized to 0, according to the C Reference
Manual (I don't have a copy of K&R handy, but I'm pretty sure it says the
same thing.) These means that integers get 0, and pointers get NULL.
(I don't know whatis supposed to happen to variables for which 0 is not
valid - what really happens is they get 0 anyhow, of course). Since this
includes all variables not explicitly initialized, it includes unions.
It is hard to imagine an implementation of this that allows a block of
memory representing simultaneously one or more pointers and one or more
integers to be initialized correctly unless the bit pattern for a null
pointer is identical to the bit pattern for a 0 integer of the same size
(assuming one exists - otherwise concatenations of integers, or whatever
else is required).
I can think of at least two ways it could happen. First, I believe a
compiler is free to treat 'union' as equivalent to 'struct' - i.e. ignore
the intended overlaying of memory. It could then initialize the two
sets of variables entirely independently. Second, I can imagine some
form of tagged memory architecture in which the tags are only used in
conjunction with instructions that use the memory as an address, so the
non-tag (i.e. the integer) is zero, but the entire location (including the
tag) is non-zero. I don't know enough about tagged memory architectures
to pursue this very far, but it seems too complex to be really credible.
Therefore, unless you accept a brain-damaged compiler that treats 'union'
as equivalent to 'struct,' it seems hard to avoid the conclusion that
C requires that the bit-pattern for a "null" pointer be identical to the
bit pattern of "(int) 0" (except possibly in length).
More information about the Comp.lang.c
mailing list