From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10107032347.AA16150@clio.rice.edu>
Subject: Re: malloc() problem, DJDEV 203
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Tue, 3 Jul 2001 18:47:01 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1010703150917.19306L-100000@is> from "Eli Zaretskii" at Jul 03, 2001 03:12:29 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> How about if we fail any allocation that's larger than what 
> __dpmi_get_free_memory_information returns in the first member of the 
> struct it returns?  Or are there DPMI hosts that lie about that?

There are DPMI hosts that lie.

> If that doesn't work, I think we can safely decline anything above 2GB, 
> which will avoid the signed/unsigned nuisance (inside malloc as well).

It's worse than that - sbrk() takes SIGNED values - you can feed it 
negative numbers to decrease the brk size.  So you should never feed
sbrk() a value over 2Gb.  I found that trying to test over 2Gb support
in a WIP CWSDPMI ...

So, since sbrk() internally adds 64K or something to the request and 
manipulates, you probably want to stay at least 2Gb - 64K away or 
something.