"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)?
