Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Uninitialized externals and statics.
Message-ID: <1989Aug22.145155.14479@twwells.com>
Date: 22 Aug 89 14:51:55 GMT
References: <2128@infmx.UUCP> <10764@smoke.BRL.MIL> <478.nlhp3@oracle.nl> <1989Aug19.053711.7462@twwells.com> <1423@csv.viccol.edu.au>
Organization: None, Ft. Lauderdale, FL
Lines: 61

In article <1423@csv.viccol.edu.au> timcc@csv.viccol.edu.au (Tim Cook) writes:
: 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.

#1: Essentially *every* compiler does this particular bogosity. That
    means that a competent programmer had better be aware of it and
    deal with it. (Let me put it another way: I don't know of any
    that don't.)

#2: We shipped *source code* to our customers. They were complaining
    because *their* compilers made the executables too large. (So
    also did, and do, ours.)

#3: No, we could *not* tell them to use another compiler. Firstly,
    they wouldn't. Second, it almost always wouldn't make a
    difference (see #1). And third, in some cases, there *weren't*
    alternate compilers.

    (Which reminds me: someone asserted that there are more 80x86's
    running C programs than any other microprocessor. I doubt it. I
    suspect that it is something like an 8051, Z80, or other equally
    puerile processor. Do you know how many typewriters, toaster
    ovens, and computer toys are out there today? Programmed in C?
    For a guess, someone might want to look up Franklin Computer's
    sales of their hand-held spellers: these are sold in the
    millions. Most has something less than an 8086 in them. And they
    are all programmed mostly in C.

    Why am I reminded? Guess which processors have the greatest lack
    of even semi-functional C compilers? And which require the
    greatest competence in programmers to make things come out
    reasonably?)

Welcome to the real world.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com