Caution for those considering MSC 5.0

[Chris Torek]

In article <1221 at wjvax.UUCP> brett at wjvax.UUCP (Brett Galloway) writes:
>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.

I will not argue on the point of style, but the latter is wrong.
C has very few basic types (there are more in the dpANS than in
K&R, but still few enough); hence something like BSS can always be
used, even if the machine architecture has something like tag bits.
The key idea here is that a small amount of code can replace a
large amount of data:  16 (if that happens to be the number) separate
kinds of `bss' can be used to initialise the 16 kinds of zero.
Arrays of structures containing differing kinds of zeros can be set
with runtime startup loops:

>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.

The compiler can do this implicitly.  C++ does this sort of thing
for static constructors, for instance.
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: chris at mimsy.umd.edu		Path: not easily reachable