Nick Sabalausky wrote:
"Christopher Wright" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Nick Sabalausky wrote:
On a side note, stack overflows are still possible anyway (whether
functional or imperative). Is there a reason (other than inertia) that
stack frames aren't set up like a dynamic array to grow as needed? (Of
course, I can understand not doing that during a debug build to help
detect unintentional infinite recursion) I realize the overhead of
checking the stack size on every function call might be undesirable, but
(not that I've given this much thought) is there no trick to set
something up to automatically trigger when the stack fills up? Or, isn't
it already detecting stack overflow anyway (I know some languages do
that)? (Of course, I'm not saying any of this would be a substitute for
TCE, just a good compliment to it.)
You allocate memory whenever you overflow the currently allocated stack.
The caveat is that it has to be contiguous to the existing stack
(virtually contiguous, not physically contiguous). In the best case, as
soon as you allocate something outside the stack, you've set a limit on
the stack size.
On Linux, if your stack exceeds its allowed size, you get SIGSEGV. You can
trap this, but you need to specify an alternate stack to do so. On my
machine, the default stack limit is 8MB, though you can change that. I
assume that setting the limit will alter the ranges that heap memory
allocation can deal with, as well.
I see, so a relocatable stack would be required, and I can see how that
would be a problem. Is it (at least in theory) possible to use paging tricks
to transparently move the stack to a location with more available space
(perhaps with the cooperation of both the OS and the GC)?
If you required a physically contiguous stack that could be logically
noncontiguous, yes. You need a logically contiguous stack that does not
need to be physically contiguous, though, so that fails. You'd have to
change pointers.
