Date: Sun, 1 Jul 2001 11:30:52 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp AT delorie DOT com Subject: Re: CWSDPMI/DJGPP integration [was Re: Peculiar behavior of program.] In-Reply-To: <3b3dcf21.sandmann@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 30 Jun 2001, Charles Sandmann wrote: > Low effort fixes - setting bottom of stack uncommitted - this would > catch recursive programs that didn't jump down too much stack at once > and skip the uncommitted section. Yes, this was considered in the past, but was never a high priority due to low benefits. Experience shows that the absolute majority of nasty crashes due to stack overflows are due to huge off-stack allocations, like a monstrous automatic array or a call to alloca with a very large argument. These won't be caught by unmapping the stack bottom. The number of cases I've seen where stack overflow _could_ be caught--those with very deep recursion--is so small that it could be considered nonexistent. I myself only had 1 such case in the last 10 years (a naive implementation of flood-fill), and the number of such problems reported here is so insignificant that I don't remember whether I've ever seen one. There used to be a problem with GCC compiling complex code (GCC uses alloca extensively, or at least used to use it). We enlarged the run-time stack of DJGPP programs to 512KB in response to that (and I think the compiler is stub-edited to even larger stack in latest ports), and those problems were never heard of since then. Since unmapping parts of the address space really only works with CWSDPMI and a couple of rarely used hosts, this doesn't seem like an important issue. However, as usual, motivated volunteers are welcome to submit patches.