Tail call elimination

"Jérôme M. Berger" jeberger at free.fr
Fri Dec 5 10:56:41 PST 2008

Hash: SHA1

Christopher Wright wrote:
> 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.

	Actually, on Linux, the stack for the main thread grows dynamically
until it reaches the allowed size. It is *not* allocated with the
full size at the start. For other threads OTOH, the stack is
allocated once and for all at thread creation.

- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger at free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger at jabber.fr   |
Version: GnuPG v1.4.9 (GNU/Linux)


More information about the Digitalmars-d mailing list