From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9907030532.AA16230@clio.rice.edu>
Subject: Re: Re: gcc-crash - and a possible solution'
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sat, 3 Jul 1999 00:32:42 -0600 (CDT)
Cc: erik2 DOT berglund AT telia DOT com, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.990701122605.10503A-100000@is> from "Eli Zaretskii" at Jul 1, 99 12:26:40 pm
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Zeroing out the allocated buffer causes it to be paged into the
> physical memory, which will probably cause different order of
> addresses we get from the DPMI server.

But more usually this is a sign of a program bug.  Since unix
systems will zero memory the first time it's touched, some
uninitialized malloc usage bugs are only caught with DJGPP.
Setting the fill sbrk flag makes DJGPP behave like unix, so the
bugs are covered up. 

> You should be able to achieve the same effect with
> `_CRT0_FLAG_FILL_SBRK_MEMORY', it also zeroes out all allocated
> memory.

If setting this flag causes it to work, its a smoking gun that
there is a program bug.