Related articles |
---|
Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-12) |
Re: Detecting endless recursion? jmcenerney@austin.rr.com (John McEnerney) (2004-01-12) |
Re: Detecting endless recursion? fjh@cs.mu.oz.au (Fergus Henderson) (2004-01-12) |
Re: Detecting endless recursion? nmm1@cus.cam.ac.uk (2004-01-16) |
Re: Detecting endless recursion? jgd@cix.co.uk (2004-01-16) |
Re: Detecting endless recursion? derkgwen@HotPOP.com (Derk Gwen) (2004-01-16) |
Re: Detecting endless recursion? torbenm@diku.dk (2004-01-16) |
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-16) |
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-16) |
Re: Detecting endless recursion? Martin.Ward@durham.ac.uk (Martin Ward) (2004-01-16) |
Re: Detecting endless recursion? vbdis@aol.com (2004-01-16) |
[22 later articles] |
From: | jgd@cix.co.uk (John Dallman) |
Newsgroups: | comp.compilers |
Date: | 16 Jan 2004 22:26:14 -0500 |
Organization: | Nextra UK |
References: | 04-01-050 |
Keywords: | debug |
Posted-Date: | 16 Jan 2004 22:26:14 EST |
witness@t-online.de (Uli Kusterer) wrote:
> The best suggestion I've been able to get from some mailing lists was
> to just put a limit on the size of my pseudo-stack and when that is
> exceeded raise an error. This is very straightforward and would be
> easy to implement (and I feel stupid for not thinking of this), but I
> have no idea how to determine this limit.
> ... My impression is that other than artifical examples like
> Ackerman's function, real code doesn't nest very deeply so an arbitrary
> limit like 100 deep should do the trick. -John]
Agreed, but making this configurable at interpreter initialisation
time is worthwhile, especially if someone might use the language to
write an interpreter for some other language. The case I hit last year
was admittedly a bit wacky:
GDB seems to be partly written in LISP. I was using it to debug a pretty
complicated library, which does some quite serious internal recursion -
maybe 100 deep - and whose test harness is a LISP interpreter. GDB, when
its LISP interpreter was faced with interpreting the recursion of the
test-harness LISP interpreter, which was calling the recursive code,
understandably barfed on some of the more complex test cases, and asked me
to run it with a command-line parameter that told it to set up a
larger-than-default stack of the GDB LISP interpreter.
---
John Dallman jgd@cix.co.uk
Return to the
comp.compilers page.
Search the
comp.compilers archives again.