Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!viccol!timcc
From: timcc@csv.viccol.edu.au (Tim Cook)
Newsgroups: comp.lang.c
Subject: Re: Uninitialized externals and statics.
Message-ID: <1423@csv.viccol.edu.au>
Date: 21 Aug 89 23:21:07 GMT
References: <2128@infmx.UUCP> <10764@smoke.BRL.MIL> <478.nlhp3@oracle.nl> <1989Aug19.053711.7462@twwells.com>
Organization: Computer Services, Victoria College, Melbourne
Lines: 28

In article <1989Aug19.053711.7462@twwells.com>, bill@twwells.com (T. William Wells) writes:
> In article <478.nlhp3@oracle.nl> bengsig@oracle.nl (Bjorn Engsig) writes:
> : The default initialization of statics and externals without explicit inital
> : values also has the advantage (at least on some systems) that the load
> : module will be smaller.  If you explicitly initialize to zero, all those
> : zeroes will be stored in the file.
> 
> At one point, we got toasted by some of our customers because our
> executables were excessively large. It seems that one of our
> programmers did things like:
> 
> int     Array[1000] = {0};
> 
> This sort of thing made the difference between a product that could
> be shipped on one floppy and one that required two.
> 
> Guk.

Let's not misappropriate blame here.  It seems to me that your compiler
should take the blame in this scenario.  Your programmer is simply making
sure of what will be in "Array" when the program starts (sounds like a
worthwhile programming practice).

It's not his fault if the compiler can't sense that he has initialized it
to the default.  Seems like a simple optimization to me.

(Of course, most C compilers produce assembler, so they could have a go at
passing the buck on this one).