Diatribe on uninitialized externs

[Doug Gwyn <gwyn>]

I have omitted much of the original text to keep the size down:

> 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.

>    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.

> 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.

>    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.

> 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.

>       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.

>       Arrays of unknown size cannot be initialized if they contain
>             non-zero values.

See above.

> 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.

> 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.