Re: [Chicken-users] Unbounded stack growth

[Shiro Kawai]

The issue could be splitted to two:

1. Whether the implementation checks stack usage more often
2. Whether the implementation terminates with more descriptive
   message than SEGV

I think John argues on the first ground, however Marc's argument
can cover both.

These days PCs have lots of heap, and busting it with incorrect
program can take long time, with some inconveniences.  (When I see
the problem the machine is thrashing crazily.)  So addressing
the option 2 itself makes sense, I guess.  I don't know
about Chicken internals enough to say handling SEGV in this
situation is feasible or not, though.

--shiro


From: John Cowan <address@hidden>
Subject: Re: [Chicken-users] Unbounded stack growth
Date: Wed, 11 Jul 2012 14:31:58 -0400

> While you're right, it's not clear that this matters enough to fix.
> It's not a *correctness* error, since every implementation will blow up
> on excessive recursion sooner or later when memory is exhausted.
> 
> If the overflow check were done, the maximum recursion depth would be
> bounded by the C heap, not the C stack.  However, inserting all those
> checks has a cost.  So it would be a question of measuring the added cost
> of the checks over a large variety of programs.  If it's consistently
> small, they should be added; if not, there should be an option to provide
> them or to turn them off.