From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10302110342.AA26713@clio.rice.edu>
Subject: Re: Checking for stack overflow
To: djgpp-workers AT delorie DOT com
Date: Mon, 10 Feb 2003 21:42:13 -0600 (CST)
In-Reply-To: <3E47CDCC.9330D67E@yahoo.com> from "CBFalconer" at Feb 10, 2003 11:05:32 AM
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

> Doing it this way also means that the system can attempt to
> increase the available stack space if it wishes.

We can't increase stack space as we are currently laid out.
We have a single block of memory.  DPMI 0.9 does not provide
full address space control.  

> I don't know just how DJGPP allocates initial (virtual) memory,
> but I assume it is a chunk for code, followed by a chunk for
> globals, followed by a variable sized chuck for sbrk, and then a
> chunk for stack.  

Code, Data, Zeroed-Data, Stack (fixed size), sbrk

An alternate way I never coded was:
Stack (starts at 0xffffffff down), Code, Data, BSS, sbrk
It depends on address wrap and no selector limits

If you run out of stack, you expand the block, copy all the contents
up the amount you expand the stack, the adjust the base address of
the selectors to match.

Since NT,Win2K,XP don't do the address wrap thing, sort of useless
today.

Would have been cool for other systems ...