Re: stack overflow at compile time
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: 28 Apr 2006 23:48:29 -0400
Henry Spencer wrote:
(snip on stack size bounds at compile time)
This is true, but uninteresting. :-) All real programs are special cases
of one kind or another, as witness the fact that human beings reason
effectively (if not always correctly) about their programs' halting
behavior all the time.
In the absence of recursion or non-trivial dynamic allocation, bounding
stack size at compile time is obviously a straightforward problem:
generate the call graph, label each arc with the stack size of the routine
being called, and find the greatest "distance" from the root to a leaf.
The maximum may occur on a path that's actually impossible, but at least
you do get a bound.
But it is difficult to tell at compile time which routines are actually
called, even though you may know there is no recursion and only fixed
sized allocation. You could, then, way overestimate the stack usage.
With recursion you could easily underestimate it, not knowing the
maximum recursion level.
-- glen
.
- References:
- stack overflow at compile time
- From: Jatin Bhateja
- Re: stack overflow at compile time
- From: Henry Spencer
- stack overflow at compile time
- Prev by Date: Re: stack overflow at compile time
- Next by Date: Re: #include what?
- Previous by thread: Re: stack overflow at compile time
- Next by thread: Re: stack overflow at compile time
- Index(es):
Relevant Pages
|
|
