Detecting endless recursion?

Uli Kusterer <>
12 Jan 2004 11:58:46 -0500

          From comp.compilers

Related articles
Detecting endless recursion? (Uli Kusterer) (2004-01-12)
Re: Detecting endless recursion? (John McEnerney) (2004-01-12)
Re: Detecting endless recursion? (Fergus Henderson) (2004-01-12)
Re: Detecting endless recursion? (2004-01-16)
Re: Detecting endless recursion? (2004-01-16)
Re: Detecting endless recursion? (Derk Gwen) (2004-01-16)
Re: Detecting endless recursion? (2004-01-16)
[26 later articles]
| List of all articles for this month |

From: Uli Kusterer <>
Newsgroups: comp.compilers
Date: 12 Jan 2004 11:58:46 -0500
Organization: T-Online
Keywords: debug, practice
Posted-Date: 12 Jan 2004 11:58:46 EST


  I've implemented my own programming language compiler and byte-code
interpreter. Since this language is intended for beginners, I'd like
it to be robust. When a user creates a function that calls itself
unconditionally, like:

int foo( int n )
      return foo( n+1 );

  my app just bombs because it runs out of memory (because my fake
stack keeps growing and growing). And the OS doesn't let me know it's
out of memory because it's happily paging out VM.

  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.

  How are you folks doing this? Right now I'm all ANSI C++. Would I need
to resort to platform-specific code for that?

Any clues or RTFMs would be appreciated,
-- M. Uli Kusterer
[The limit you one is one deeper than the deepest program that's not stuck
in a loop. 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 shoulddo the trick. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.