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