X-Sybari-Trust:	d334ce4b 9ffcebbb 22f6c2a2 00000138
From:	Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
Message-Id:	<200302061238.NAA19735@lws256.lu.erisoft.se>
Subject:	Re: Checking for stack overflow
To:	djgpp-workers AT delorie DOT com
Date:	Thu, 6 Feb 2003 13:38:06 +0100 (MET)
In-Reply-To:	<Pine.OSF.4.51.0302061333090.25864@sirppi.helsinki.fi> from "Esa A E Peuha" at Feb 06, 2003 02:04:02 PM
X-Mailer:	ELM [version 2.5 PL3]
MIME-Version:	1.0
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

Esa said:
> On Wed, 5 Feb 2003, Eli Zaretskii wrote:
> 
> > Why not jump to __djgpp_traceback_exit instead?
> 
> After printing "out of stack", you mean?  Maybe, but the traceback
> doesn't seem very useful to me in this case.

That would give the coder a pointer to where the stack was
overflown. That could be useful.

> Here's another thought: how about having an uncommitted memory page just
> below the stack?  Then stack overflow would be just like dereferencing a
> null pointer; caught with no run-time overhead (but only on DOS machines
> unfortunately).

Except that wouldn't catch "void f(void) { int my_array[1024*1024];
my_array[2*1024] = 0; }" or similar.

Perhaps if we reserved 1GiB or something below the stack. But then we
wouldn't catch "my_array[2*1024*1024*1024] = 0"; plus that's starting
to inhibit the real code space. OTOH, perhaps that's ridiculous?

Still it'll only work in plain DOZE.


But that stack check option sounds good.


Right,

						MartinS

- Raw text -