Newsgroups: comp.os.msdos.djgpp
From: Peter Berdeklis <peter AT atmosp DOT physics DOT utoronto DOT ca>
Subject: Re: Linux to DOS Problem 
Message-ID: <Pine.SGI.3.91.970812201412.27484A-100000@atmosp.physics.utoronto.ca>
Nntp-Posting-Host: chinook.physics.utoronto.ca
Sender: news AT info DOT physics DOT utoronto DOT ca (System Administrator)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Organization: University of Toronto - Dept. of Physics
In-Reply-To: <Pine.SUN.3.91.970810175343.4651X-100000@is> 
Date: Wed, 13 Aug 1997 00:16:13 GMT
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970810175343 DOT 4651X-100000 AT is> 
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Sun, 10 Aug 1997, Eli Zaretskii wrote:

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


The language definition specifies the value of uninitialized _auto_ 
variables, but not of raw memory allocated by malloc or new.  This memory 
is undefined.  That's where the problem with v1.x and v2.0 came from.

I think you both know this, but where discussing different things.

---------------
Peter Berdeklis
Dept. of Physics, Univ. of Toronto