From: "emry" <sandemos AT hotmail DOT com DOT spamblock>
Subject: Re: Linux to DOS Problem
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970810175343 DOT 4651X-100000 AT is>
Organization: none
Message-ID: <01bcadd2$78d51860$28071dac@d-080>
Newsgroups: comp.os.msdos.djgpp
Date: Wed, 20 Aug 1997 18:37:08 -0700
Lines: 39
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

This may just be a habit learned from using basic, but as a general rull
isn't it a good Idea to initialize a variable (ie set it to 0 or other
appropriat number) before using it if random numbers are going to be a
problem?  I know that many ports of basic set a new variable to zero but
many ports of pascal do not.  
If you feel I am just rambling, then feel free to ignore me.  :)

-- 
Kenneth M. Burling
Send email
emry AT nova1 DOT net
the email address in the header is modified to prevent spamming.

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote in article
<Pine DOT SUN DOT 3 DOT 91 DOT 970810175343 DOT 4651X-100000 AT is>...
> 
> On Tue, 5 Aug 1997, Erik Max Francis wrote:
> 
> > Paul Derbyshire wrote:
> > 
> > > Sounds like maybe the value depends on uninitialized memory.
Different
> > > platforms treat it differently; one compiler or GCC on one platform
may
> > > initialize all memory used at zero; another or GCC on another might
> > > leave
> > > it random.
> > 
> > I find that to believe.  The undefinedness of uninitialized auto
variables
> > is built into the language, and gcc is well aware of it.  gcc for Linux
> > and DJGPP are just ports of the same thing, after all.
> 
> That's true, but the memory for the uninitialized variables comes from
> the runtime memory allocation functions.  If those zero the memory,
> you have zero initial values.  I recall vaguely that this was one of
> the main problems when porting v1.x library to v2.0: some of the
> functions assumed memory was zeroed.
>