Message-ID:	<3E47CDCC.9330D67E@yahoo.com>
Date:	Mon, 10 Feb 2003 11:05:32 -0500
From:	CBFalconer <cbfalconer AT yahoo DOT com>
Organization:	Ched Research
X-Mailer:	Mozilla 4.75 [en] (Win98; U)
X-Accept-Language:	en
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Checking for stack overflow
References:	<10302071430 DOT AA20844 AT clio DOT rice DOT edu> <Pine DOT OSF DOT 4 DOT 51 DOT 0302101329270 DOT 31820 AT sirppi DOT helsinki DOT fi>
Reply-To:	djgpp-workers AT delorie DOT com

Esa A E Peuha wrote:
> On Fri, 7 Feb 2003, Charles Sandmann wrote:
> 
... snip ...
> >
> > If near pointers are enabled, or under Windows where it can do
> > the address wrap thing behind your back - no ...
> 
> OK.  Here's what I wrote during the weekend.  Assuming that esp
> has already decremented to point to the newly allocated space,
> the possible overflow is detected thus:

I don't believe you should make any such assumption.  You cannot
assume that anything called has stack checking code.  So I
consider you should ONLY check at function entry, when stack space
is being allocated for locals.  This can be done by forming a
value from the current sp and the (global) value of sp_limit, and
comparing to the proposed allocation size.  The comparison can
include a margin sufficient for calling (known) handling routines,
which is again a compile time constant.

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

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.  The behaviour I have seen for sbrk allows it to
allocate areas below the above chunks, and then start to dole out
the space I mention above, so its real top is the maximum of the
globals and the current sbrk value.  The stack limit should be
some (known) margin from that.  Utilizing it may require
allocating further virtual memory, but that is a separate issue. 
This whole hypothetical mechanism can be triggered by the
detection, which needs to be short and efficient.

Such a mechanism also means that sbrk has to detect the current
stack limit and refuse to allocate anything that would infringe on
it.  After all that failure depends solely on the inability to
allocate further virtual memory.  Such a mechanism avoids ever
having to specify stack limits for a program.  It eliminates
complaints from newbies who try to allocate 66 megabytes of local
storage.

I.E. sbrk is a stack that grows upward.  sp is a stack that grows
downward.  When they meet, failure, else expand virtual memory
(which can fail).  The only valid limit on a program is
total_memory_resources, whose value is an entirely different
policy decision.

At least as I see it.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

- Raw text -