Date:	Mon, 1 Dec 1997 17:18:18 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
cc:	djgpp AT delorie DOT com
Subject:	Re: G++ bugs?
In-Reply-To:	<m0xcRmr-000S23C@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.971201171237.9364B-100000@is>
MIME-Version:	1.0

On Mon, 1 Dec 1997, Salvador Eduardo Tropea (SET) wrote:

> Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> > 
> > GCC doesn't care about where its memory comes from.  If anything, that 
> > should be some bug in DJGPP-related stuff (either malloc, or the startup 
> > code or in CWSDPMI).
> Are you 100% sure?

Of course I'm not 100% sure.

> If GCC have bugs writing out-of bounds the amount of memory 
> can change the scheme and generate different corruptions.

That's a possibility.  But my experience is that most of such problems in 
GCC are DJGPP-specific.  Out-of-bounds bugs are easy to track with tools 
such as efence and I'd imagine they wouldn't be too frequent.

> I'm not sure 
> if that can trigger the checks in GCC, but I think that isn't in 
> malloc, and I know isn't related with CWSDPMI because I saw it under 
> W95.

W95 *and* CWSDPMI, or only W95?  If it's only W95, maybe it refused GCC's 
allocation request, and either GCC or our `sbrk' barfed?

> > Another possibility is that your TMPDIR was pointing to a small RAM 
> > drive.  GCC doesn't recover graciously when the temporary space is 
> > exhausted.
> But can the use of TMPDIR change when the amount of memory changes?

When people have more RAM, they frequently enlarge their TMPDIR, if it's 
on the RAM drive.

- Raw text -