Andrei Alexandrescu wrote:
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).
Somebody more resourceful than I might /prove/ some maximum for any
program that doesn't use recursion (be it implicit or explicit
recursion). Hello.d attempted to be an example of such a program.
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.
Of course. And there's a limit to the stack size, ultimately at the
hardware level. For any increase in available stack size, the
probability of an out-of-stack exception decreases, never reaching zero.
I agree.
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.
It'd be useless if we were attempting to give 100.000% guarantees.
I can't believe you brought it up as anything else but jesting
(maybe you are and I'm not getting it).
Jesting on a level where you might not get it, wouldn't be fun. And
definitely boring and confusing to the rest of the crowd. :-)
Maybe I'll have to dig up prior art, or something. Clearly I'm not
qualified to properly defend the validity of this idea.
