Diatribe on uninitialized externs

[Kevin Martin]

>>I wrote:
>Doug Gwyn writes:
>> There seem to be four alternatives for what to do with externs and statics
>> which are not explicitly initialized:
>> 
>> 1) Have their value be undefined (i.e. garbage).
>>    Disadvantages:
>>       Breaks many current programs.
>
>Very important from an economic standpoint.
Yes. That is why I am not advocating this alternative.

>>    Advantages:
>>       Allows the programmer to get genuine "bss" (un-initialized) space.
>>             This becomes especially important if overlays are being used,
>>             since it may be desired that an overlay be loaded without re-
>>             initializing all the variables it contains (note 4).
>Any overlay system that reinitializes variables is WRONG.
Depends what you want. But as I said, I am not advocating this alternative
for C.

>> 2) Have their value be the 0 bit pattern.
>As has been pointed out in another discussion, the 0 bit pattern may
>not be appropriate for pointers on some machines.
Whether it is appropriate for some machines does not affect its
existance as an alternative.
The point I made was to consider whether it is ANSI's goal to support
old code on new machines. I realize there are such machines; I have to
write a C compiler for at least two of them. Complete with non-zero
NULL pointers.

>>    Disadvantages:
>>       Arrays of unknown size containing floats, doubles or pointers
>>             cannot be initialized (note 1).
>If all elements are to be initialized to the same value, then this
>statement is false.  The last explict initializer is repeated as necessary
>to fill out the array.
Oh yeah? Since when? k&r appendix A section 8.6 paragraph #5 says missing
items get zeroed.

>> 3) Have their value set to a zero of the appropriate type.
>>    Disadvantages:
>>       Requires a somewhat arbitrary rule on "what is the appropriate type
>>             for a union?"
>Easy; the type of the first member.
As I said, an arbitrary rule. I didn't say it would be difficult to come up
with one. Besides, who says I always want the same variant of the union
initialized. What if one array uses the 'int' element (so I want int zeros),
and another array uses the pointer element (so I want NULL's)?
>
>>       The programmer cannot signal to the reader that a variable is
>>             deliberately being left un-initialized.
>Sure he can.  Nothing prevents you from specifying initializers you care
>about and letting the rest default.  I do this anyway.
If you do this anyway, why do you care about this pariticular discussion?
That's fine & dandy if I can be sure that whoever wrote the code was as
diligent as you and I are about initializing things we really care about
(and drank enough coffee that day, etc.)
I agree, he can signal deliberately *initialized* ones. But given a declaration
like
	int x;
I can't tell if he really cares that there is a zero there, if he forgot
to initialize it, or if he doesn't care what is in it. This is what I
mean by deliberate *lack of initialization*. It is (partly, at least)
a statement of my opinion (and yours, judging from your comment above) that
a programmer should always use explicit initializers if the initial value
matters. If that practice were followed by everyone, this discussion
would hardly be as exciting. Unfortunately, it isn't always possible,
if you have a union or an array.

>>       Arrays of unknown size cannot be initialized if they contain
>>             non-zero values.
>See above.
Yes, please do.
>
>> 4) A combination of (1) and (2):  Un-initialized variables start off as
>>    zero in the first overlay that is loaded. Subsequent overlays get whatever
>>    was left in the storage location by previous overlays.
>The C language says nothing about overlays.  This is an implementation
>issue that must be addressed by the overlay system designer, but it
>does not belong in the language specification.
The language should not make the "overlay system designer"'s job impossible.
The language spec doesn't even have to mention overlays. It merely has to
say what happens to un-initialized variables.
>
>> Ignoring the problems of upward compatibility and lazy programming
>> styles, choice (1) is the winner. However, given that old
>> programs must continue to work, Choice (4) looks like the best one.
>
>> If the committee goes for choice (3) now, this will only encourage code
>> which doesn't explicitly initialize things, and make for an even larger
>> base of software to break when the next standard tries to go back to
>> choice (1) or (2).
>
>I vote for choice (3).  I don't see that arrays or overlays have anything
>to do with the choice among these alternatives.  (3) is cleanest.
As far as 'cleanliness', I disagree, but I admit that this is just an
opinion

What I was trying to state is that there are two ways to solve the problem
of hostile machines (without them, this problem wouldn't exist).
One method is better CPP; it requires extensions to CPP, and the programmer
   will have to type (as in keyboard, not as in typedef) more, but this
   approach is far more powerful (for going *beyond* a minimal solution
   to the original problem). It even lets you initialize all the rest of
   the array elements to a non-zero value (as you seem to think C can
   already do).
The other method is this implicit zero-of-the-right-type initialization.
   It solves *only the immediate problem* and is otherwise a dead end.

These two solutions are not incompatible, but implementing both of them
(eventually...) will give no advantages over just the CPP solution,
but will have the disadvantages of both.

I doubt that any CPP changes are forthcoming in this standard, but I don't
like stopgap solutions, either.

I would rather see it stay as is for now (zero bit pattern).
Bear in mind that I use such hostile machines in my regular work, and
have encountered no problems with the current rules (other than not
being able to tell deliberate un-initialized from deliberate but implicit
zero, a problem which is not solved by typed-zero initialization).
                  Kevin Martin, UofW Software Development Group