Re: [Chicken-users] Unbounded stack growth

[Marc Feeley]

On 2012-07-11, at 2:31 PM, John Cowan wrote:

> Marc Feeley scripsit:
> 
>> In this example, there will be an arbitrarily long sequence of C calls
>> (in the unwinding of the recursion to even) with no Scheme call, so
>> stack size checks will not be performed during the unwinding, yet the
>> C stack grows during the unwinding.  There is no stack overflow during
>> the winding phase of the recursion because the stack size checks are
>> performed at regular intervals (at each entry to even).
> 
> While you're right, it's not clear that this matters enough to fix.
> It's not a *correctness* error,

Saying that this is not a correctness error is lawyer-speak.

> since every implementation will blow up
> on excessive recursion sooner or later when memory is exhausted.

Part of the problem is that it truly "blows up".  A high-level language should 
never give a segment violation.  If there isn't enough memory, a software 
exception should be raised (possibly catchable), or at a bare minimum a 
readable error message (such as "stack overflow").

> If the overflow check were done, the maximum recursion depth would be
> bounded by the C heap, not the C stack.

On my 64 bit machine, the C heap is several orders of magnitude larger than 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.

Performance should not trump safety and correctness.

Marc