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

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

- Raw text -