Message-Id: <m0xcluP-000S1zC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Organization: INTI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Date: Tue, 2 Dec 1997 09:42:19 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: G++ bugs?
References: <m0xcRmr-000S23C AT inti DOT gov DOT ar>
In-reply-to: <Pine.SUN.3.91.971201171237.9364B-100000@is>
Precedence: bulk

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 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.
Ok, I think the same.
 
> > 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?

The problems appears in both. And I experimented it a lot of time ago with Win 
3.1. And isn't just in my machine because I saw it at work too. I think is more 
related with the memory layout created when GCC allocates the memory, but the 
probabilities to hit it are bigger with less memory. Normally if you have a lot 
of *physical* memory you never see it.

> > > 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.
Isn't my case I have the same TMPDIR under W95 and DOS 6.2+CWSDPMI in my 
machine.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013