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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
