Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.lang.c Subject: Re: Diatribe on uninitialized externs Message-ID: <5494@brl-tgr.ARPA> Date: Mon, 29-Oct-84 00:02:42 EST Article-I.D.: brl-tgr.5494 Posted: Mon Oct 29 00:02:42 1984 Date-Received: Tue, 30-Oct-84 01:18:03 EST References: <9572@watmath.UUCP> Organization: Ballistic Research Lab Lines: 69 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.