Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: Diatribe on uninitialized externs
Message-ID: <4535@utzoo.UUCP>
Date: Thu, 25-Oct-84 14:35:04 EDT
Article-I.D.: utzoo.4535
Posted: Thu Oct 25 14:35:04 1984
Date-Received: Thu, 25-Oct-84 14:35:04 EDT
References: <9572@watmath.UUCP>
Organization: U of Toronto Zoology
Lines: 42

It is definitely much too late to remove default initialization from C;
far, far too much code depends on it, including the Unix kernel.  Adding
features is one thing.  Taking them away is another.

Note that "not breaking existing correct code" is a major objective of
the ANSI committee.  This means that default initialization must be
present, and must follow either the zero-bit-pattern or as-if-integer-0
rule.  The oddball machines are the only ones that pay a penalty for the
wrong choice, so it comes down to a simple question of whether the
people with such machines would rather maximize portability of older
software to their machines, or maximize the efficiency (object-module
size and load time) of new code.  This is clearly a case where those
of us with un-oddball machines should keep quiet; it is presumptuous of
us to tell the oddball-machine people "we know what you ought to want".
I suspect that really odd machines may end up with a compiler option to
settle the matter; probably the default setting should be "portable".

If overlays are being used mostly to get more code into a limited space,
then clearly they should not affect the data.  Such overlays are logically
just an implementation technique for fitting lots of code into a small
space, and (ideally) should not be visible on the language level at all.
If it is specifically desired that overlays overlay the data space as
well (i.e. act like exec()), then there's no problem.  If what you have
is something in between, then I think the only practical answer is that
your techniques and the problems associated with them are implementation-
dependent and are not a standards issue.  Depending on what sort of overlays
you have, the data gets left alone, or trashed, or re-initialized wholly
or partly; I see no reason for an ANSI standard to try to bless one kind
of overlays and condemn the others.

> If the committee goes for [integer-0] 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
> [no-default-initialization] or [zero-bit-pattern].

Why in the world would the next standard do anything so stupid?  You are
setting up a straw man.  Of course there will be hell to pay if the next
standard goes out of its way to be incompatible with the current one, but
that's true regardless.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry