X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10205170350.AA15854@clio.rice.edu>
Subject: Re: Malloc/free DJGPP code
To: djgpp-workers AT delorie DOT com
Date: Thu, 16 May 2002 22:50:09 -0500 (CDT)
In-Reply-To: <3CE41DBB.B1DB75C4@yahoo.com> from "CBFalconer" at May 16, 2002 04:59:39 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

> > The DJGPP implementation of sbrk does accept a negative argument, but
> > it doesn't return that memory to the system.
> 
> So, what does it do with that memory.  Is it simply abandoned? 

No, it's just sitting there, still allocated, waiting for you to ask
for it again with sbrk() with a positive value.

> What does it do if the argument is the negative of the total size
> allocated continuously so far?  

It would set the selector limits to zero, the start of the allocation
space to zero, and you would die very badly (you would in effect be
making all the code, data and stack not available).  In any case you
pass a negative number, you may be making stack/data required to run
be unavailable.

> What if the negative argument is
> larger magnitude that what has been allocated?  

It either fails, or it would be treated as a huge positive value 
(and fail when DPMI was unhappy returning 3.8Gb of memory in a single 
block).  Then you would probably get a return of -1.

> What happens on a subsequent call for a normal positive size?  

If you haven't aborted something, it should just increase the "break"
point by the amount you added (to the last successful return).

> If these things can foul it up nmalloc should protect against 
> generating such calls with oversized requests.  

As a matter of fact, the current CVS malloc has some additional protections 
against "fluffy" allocations over 2Gb in size in malloc to fix these
sorts of issues (and would need to be in the new version too).

> Maybe it could limit allocation requests to INT_MAX after rounding up.

Minus some fluff for roundup.  It's in CVS malloc already.

Note, it is possible to use more than 2Gb of address space in a DJGPP
application if you use multiple sbrk() calls and beware signed/unsigned
problems.  (I've tested CWSDPMI versions with more than 2Gb).