From: "A. Sinan Unur" <asu1 AT cornell DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: malloc() problem, DJDEV 203
Date: 3 Jul 2001 02:35:52 GMT
Organization: Cornell University
Lines: 27
Sender: verified_for_usenet AT cornell DOT edu (asu1 on slip-32-102-40-109.ny.us.prserv.net)
Message-ID: <Xns90D2E5B62E697ASINANUNUR@132.236.56.8>
References: <Pine DOT SOL DOT 4 DOT 33 DOT 0107022250120 DOT 27631-100000 AT holyrood DOT ed DOT ac DOT uk> <200107022219 DOT SAA04299 AT envy DOT delorie DOT com> <Pine DOT SOL DOT 4 DOT 33 DOT 0107030043180 DOT 14632-100000 AT holyrood DOT ed DOT ac DOT uk> <200107022351 DOT TAA05124 AT envy DOT delorie DOT com> <Pine DOT SOL DOT 4 DOT 33 DOT 0107030132070 DOT 19125-100000 AT holyrood DOT ed DOT ac DOT uk> <200107030107 DOT VAA05731 AT envy DOT delorie DOT com>
NNTP-Posting-Host: slip-32-102-40-109.ny.us.prserv.net
X-Trace: news01.cit.cornell.edu 994127752 23077 32.102.40.109 (3 Jul 2001 02:35:52 GMT)
X-Complaints-To: usenet AT news01 DOT cit DOT cornell DOT edu
NNTP-Posting-Date: 3 Jul 2001 02:35:52 GMT
User-Agent: Xnews/4.06.22
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

DJ Delorie <dj AT delorie DOT com> wrote in 
news:200107030107 DOT VAA05731 AT envy DOT delorie DOT com:

>> There seems to be another problem as well. Some significantly smaller
>> requests that are still large enough that they must fail, e.g.,
>> 4294378000U bytes, also cause malloc() to return non-NULL. 
> 
> I wouldn't trust any request bigger than 2G, because you never know
> when the OS is going to treat the number like a signed number.  sbrk()
> is the interface to the OS; has anyone tried testing that
> independently of malloc?  And has anyone tried testing GNU malloc to
> see if it has the same problems?

On a whim, I tried it ... in a DOS box under Win 98 SP1 w/96 MB physical 
memory, go32-v2 reports:

DPMI memory available: 43136 Kb
DPMI swap space available: 51816 Kb

Anyway, GNU Malloc seems to work as expected (returning null) for large 
allocations up to 0xFFF5FFFF. After that it goes into an infinite loop (can 
still do CTRL-BREAK to exit).

-- 
--------------------------------
A. Sinan Unur
http://www.unur.com/