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
