Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!ho7cad!ekb
From: ekb@ho7cad.ATT.COM (Eric K. Bustad)
Newsgroups: comp.lang.c
Subject: Re: Caution for those considering MSC 5.0
Message-ID: <278@ho7cad.ATT.COM>
Date: 17 Feb 88 14:29:00 GMT
References: <11754@brl-adm.ARPA> <620@viper.Lynx.MN.Org>
Organization: AT&T Bell Laboratories, Holmdel, NJ
Lines: 26

In article <620@viper.Lynx.MN.Org>, john@viper.Lynx.MN.Org (John Stanley) writes:
> In article <11754@brl-adm.ARPA> PEPRBV%CFAAMP.BITNET@husc6.harvard.EDU (Bob Babcock) writes:
> .......
>  >The manual seems to indicate that only initialized global
>  >data  will  go  here,  but  isn't  all  global   data  implicitly
>  >initialized to zero if not otherwise specified?
> 
>   It's true on "many", but not all systems.  Rule of thumb is NEVER 
> assume any UN-initialized variable contains zero (or NULL)...  If you
> haven't explicitly put something into a variable, assume it's set to 
> a random value or the constant most likely to cause your procedure to 
> bomb....

Actually, K&R says on page 198:  "Static and external variables which are
not initialized are guaranteed to start of as 0".  If a compiler does not
arrange for this to happen, then it is not a C compiler.  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.

As for how MSC 5.0 handles "uninitialized" globals, I imagine that it is
doing the same thing as all of the C compilers I've ever used.  All of the
static variables which are implicitly initialized to zero are placed in a
separate section called BSS.  Only the size of this section needs to be
stored in the object file, saving mucho disk space.

= Eric Bustad