Caution for those considering MSC 5.0

Brett Galloway brett at wjvax.UUCP
Sat Feb 20 07:06:33 AEST 1988


In article <2635 at haddock.ISC.COM> karl at haddock.ima.isc.com (Karl Heuer) writes:
>In article <278 at ho7cad.ATT.COM> ekb at ho7cad.ATT.COM (Eric K. Bustad) writes:
>>As a matter of style, however, I agree with John that one should explicitly
>>initialize any variable if your code makes any use of its initial value.

It has long bothered me that C guarantees that uninitialized data of static
extent gets initialized to 0.  Personally, I *never* rely on that fact, for
two reasons.  One is a matter of style (see above).  The other is a matter
of principle.  This guarantee is useless and can introduce enormous
inefficiencies.  Unless your machine obeys the convenient kludge that binary 0
translates to a 0 object of every type, then in general a copy of the entire
uninitialized data space must be put in the executable and loaded into
memory.  Something like BSS is completely useless then.

In those cases where I have a lot of data that needs to be initialized, it
is usually the case that it is fairly simple to initialize with code, and so
I just keep a static initialized flag to indicate whether or not to
initialize the rest.

I can see where the inefficiency above could raise even more efficiency
problems for a non-hosted system (on PROM).  A C application in PROM must
keep a copy of the static data area in PROM and copy it to RAM prior to
running.   Implicitly initializing the entire static data area can in general
greatly increase the size of PROM needed.  An equivalent assembly language
implementation would of course just use BSS, and would be *much* smaller.

Anyhow, I think that this is a botch in C; it is a shame that it can't be
changed.  Maybe D?

-- 
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett



More information about the Comp.lang.c mailing list