From: j DOT aldrich6 AT genie DOT com Message-Id: <199607110154.AA100990054@relay1.geis.com> Date: Thu, 11 Jul 96 01:39:00 UTC 0000 To: a DOT appleyard AT fs2 DOT mt DOT umist DOT ac DOT uk Cc: djgpp AT delorie DOT com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: Re: What if I run out of store Reply to message 6741051 from ELIZ AT IS DOT ELTA. on 07/10/96 7:34AM >> In djgpp version 2, how can I find at run time how much free stack space >> is left? > >You can get the address of the farthest (lowest) location of the stack (by >calling `alloca (256K)' at the beginning of `main') and then look at the >difference between that value and the addresses of your automatic >variables. I didn't test this, though, so I might miss something here. That sounds like it would work. Then you could write a function which examines its own stack frame and subtracts that address from the base stack address to determine how much stack is being used. The only problem is comparing that value to the actual size of the stack, and I am not sure how to go about determining that. A couple of things come to mind immediately: 1) If you set _stklen within your program, then you can just examine that, but is _stklen defined if you didn't do it yourself? 2) Also, what about STUBEDIT being used to increase (or decrease) the runtime stack? This would, for obvious reasons, invalidate the internal value of _stklen, unless it is changed by the program itself at runtime. 3) What about running the program under a debugger like gdb, which has its own runtime stack? Obviously, a portion of that stack would be used for gdb itself, so the aforementioned call to 'alloca()' wouldn't return the true top of the stack. Actually, now that I think about it, gdb probably uses the heap itself before invoking the debuggee, so your program wouldn't be starting with a clean slate to begin with. You may be able to determine the lower boundary of the stack by calculating the address of the _last_ statically allocated variable in your program. But you would have to account for local static variables as well as global ones. Also, if you read the section in the FAQ which deals with increasing stack space, it implies that unless the size of the stack that thestub allocates for your program is >= the size you specified in _stklen, the stub's stack is discarded and a completely new stack is allocated, essentially wasting the space for the stub's. If this space is contiguous with the new stack, then overwriting it causes no serious problem, but if it isn't then the top of static storage and the bottom limit of the stack will _not_ be the same! Now that I think about it, I imagine that these may be some of the reasons why Charles didn't implement stack overflow checking in CWSDPMI. (Or, for that matter, why it is not generally implemented in DPMI, period.) ;) John