Must a NULL pointer be a 0 bit pattern?

[Kevin Martin]

>   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".
It is indeed the case that K&R isn't very rigorous on that point.
I have always read "guaranteed to start off as 0" as denoting the bit
pattern, rather than the interpretation of the bit pattern in any particular
type.

I would prefer that uninitialized variables be just that: uninitialized,
but initializing to the *bit pattern* of zero bits is second best.

>   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

As for explicit initializers, I certainly don't see a good reason for
picking the first element of a union; it is very likely that in two
variables of the same union type, I would want the initialization to
occur to two different elements.

It would be far more advantageous to add a method of explicitely naming the
union element you want to hit. As a side effect of the required syntax, you
could also initialize array and struct elements in any desired order.
Unfortunately, this would require additions to the language, which is
not what the committee is out to do, etc. etc.
                     Kevin Martin, UofW Software Development Group