X-Sybari-Trust: d334ce4b 9ffcebbb 22f6c2a2 00000138 From: Martin Stromberg 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: from "Esa A E Peuha" at Feb 06, 2003 02:04:02 PM X-Mailer: ELM [version 2.5 PL3] 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 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