Message-ID: <3E47CDCC.9330D67E@yahoo.com> Date: Mon, 10 Feb 2003 11:05:32 -0500 From: CBFalconer 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. USE worldnet address!