Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!linus!decvax!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: Re: Diatribe on uninitialized externs
Message-ID: <9691@watmath.UUCP>
Date: Sat, 3-Nov-84 10:40:11 EST
Article-I.D.: watmath.9691
Posted: Sat Nov  3 10:40:11 1984
Date-Received: Sun, 4-Nov-84 04:42:12 EST
References: <9572@watmath.UUCP> <5494@brl-tgr.ARPA> <9633@watmath.UUCP> <5563@brl-tgr.ARPA>
Reply-To: kpmartin@watmath.UUCP (Kevin Martin)
Organization: U of Waterloo, Ontario
Lines: 57

>	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