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