Georg Wrede wrote:
Andrei Alexandrescu wrote:
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Computing the stack depth even for non-recursive functions is an
interprocedural analysis so it's difficult to do modularly. The
stack is also unchecked so going with a "good enough" approximation
is bound to be risky.
The old size estimation problem. No matter how big you decide on,
somewhere is an idiot who will blow that size too.
A runtime solution just occurred to me. The newly allocated stack for
a thread is zeroed first, right? Well then, just before the thread
finishes, one could scan the stack area, and find the first address
that contains a non-zero value.
This isn't bullet proof in theory, but hey, the aim is to help in
/estimating/ the needed stack size.
You can't be more serious than Mark Twain when giving advice on the
stock market: "Buy some stock. If it goes up, sell it. If it doesn't
go up, don't buy it."
I'd be amazed if the stack usage of hello.d varied from run to run.
I'd be amazed if hello.d were your prototype of a useful program :o).
Let's face it. Any program that uses mutual recursion of any kind (even
when the user did not set out to use recursion) or that uses alloca
(fewer), is bound to have the consumed stack dependent on the input.
Even without recursion, various traces of a program depend on a data and
have different stack depths. That's why your estimate is utterly
useless. I can't believe you brought it up as anything else but jesting
(maybe you are and I'm not getting it). I can't even believe I'm
replying! :o)
Andrei
