From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10302071430.AA20844@clio.rice.edu>
Subject: Re: Checking for stack overflow
To: djgpp-workers AT delorie DOT com
Date: Fri, 7 Feb 2003 08:30:34 -0600 (CST)
In-Reply-To: <Pine.OSF.4.51.0302071221550.25428@sirppi.helsinki.fi> from "Esa A E Peuha" at Feb 07, 2003 12:53:38 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

> Actually, I think we may assume that if a function is compiled with
> -fstack-check then it will only be called when esp points to the normal
> application stack.  In that case it's sufficient to simply compare esp
> against __djgpp_stack_limit, so there's no need for any new global
> variable.

I agree.  I was thinking about it last night, and if you are on the
exception stack (a whopping 8KB in size) the entire point is to either
exit or longjmp back to someplace else.  So signal handlers should
not be compiled with -fstack-check, nor should dpmiexcp.c.

> > We really need
> > to be able to make sure that the right signed/unsigned behavior is
> > done with this or it's not very useful (big automatic arrays can cause
> > ESP to not only go into data or code, but actually below 0 and into
> > uncommitted space).
> 
> Won't that cause an exception even now?  But I'll keep that in mind.

If near pointers are enabled, or under Windows where it can do the
address wrap thing behind your back - no ...