Yet another strike against the current AA implementation

[Georg Wrede]

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.