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/

- Raw text -