X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Fri, 17 May 2002 10:22:25 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <1438-Fri17May2002102225+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <10205170350.AA15854@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: Malloc/free DJGPP code
References:  <10205170350 DOT AA15854 AT clio DOT rice DOT edu>
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

> From: sandmann AT clio DOT rice DOT edu
> Date: Thu, 16 May 2002 22:50:09 -0500 (CDT)
> 
> > 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

I'm confused: didn't you just tell that negative arguments to sbrk
don't modify the memory allocation as far as the DPMI host is
concerned?  That would mean we still own the memory the application
wanted to return, and thus the selector limits should not change at
all.  All that should have changed is the value stored in
_what_size_app_thinks_it_is.

In other words, I thought the selector limit (and, possibly, the base
address) only changes when we allocate _additional_ memory off the
DPMI.  What am I missing?