Diatribe on uninitialized externs

[Kevin Martin]

>	foo =	{
>		,
>		3.14159,
>
>		};
>using explictly empty members in the initializer (this would apply to
>structs as well as unions).  The only incompatibility with current C
>that I see here is the slightly different meaning of the final , in
>the initializer list.
This implies that the ordering of union elements is significant, which
is currently not the case. But the 'zero-according-to-the-type-of-the-
first-union-element' rule also does this.
I would still prefer to name the element when I am explicitly initializing
it, but that is a different discussion.

>If the rule is that uninitialized data is filled with proper-typed zero,
>then it seems that you wouldn't have to care which [don't-care about the
>value vs. wanting a zero] was intended...
When I go to modify code which was written by someone else (or by
myself in the long-forgotten past), I do care. If it was deliberately
left un-initialized, but I don't realize this, and I now give it an
explicit initializer (non-zero) for some purpose, it will have
no effect, because of the initialization code which I failed to
look for. And I can't trust other people to have explicitly initialized
*every* variable they cared about.

>The problems would appear to
>be due to trying to follow different rules, for example using specially-
>tagged "illegal data" values or "not defined" memory manager traps for
>uninitialized data instead of zero.  By the way, I think we should beat
>on the hardware designers who keep dreaming up these "helpful" features
>without checking with compiler/OS implementers to see what their effects
>will be.  If possible, buy more reasonable hardware and TELL the loser
>of the competition just what's wrong with his fancy design.
I always did like somple machines like the Nova... there were so few
ways of doing anything that most of the code was already optimal!
Unfortunately, in the cases I am working with, guess who is paying me
(indirectly). At least I don't have the funny undefined values and tags
you mention.

>
>I think I will modify my position:  IF uninitialized data HAS to have
>some valid value, then I would (still) recommend 0 of the appropriate
>type rather than a 0 bit pattern.  This seems to be compatible with
>currently portable C code.  However, if one is willing to drop the
>compatibility requirement (apparently the ANSI committee is not), then
>I would have uninitialized data contents UNKNOWN, possibly trap-causing,
>if they are used before being defined.  That would help stamp out sloppy
>coding practices (nothing will completely solve this problem).
>Doug Gwyn
That seems to reflect my feelings for the *eventual* resolution of this
question. Once having chosen one of these paths, there will be no backing
out, which is why I am loathe to choose either of them in the first standard.

I think we've run out of things to discuss... (I hear the entire net breathe
a sigh of relief)
                       Kevin Martin, UofW Software Development Group