Stack frames larger than 4K should be rejected, but what if I want more

[Ola Fosheim Grøstad]

On Monday, 28 June 2021 at 08:54:59 UTC, IGotD- wrote:
> Hitting guard pages and you will get an exception and a core 
> dump. That's one way to do it but there is no explicit message 
> that you ran out of stack. By checking the stack limit for each 
> frame you can gracefully exit and print a message. Any of these 
> methods gives you a performance hit and I am a bit skeptical 
> that it is worth it. I think it should be an opt in feature.

You should be able to trap it and use the program counter/stack 
pointer to figure out where it happened. Then you can extend the 
stack if you are able to, if not call a cleanup handler.

The best thing is obviously to prove that the stack usage will 
stay within a worst case estimate. That is what you want in 
embedded and comparable applications. That should obviously be 
opt in, as it prevents arbitrary recursion, but then you also 
need no guards and other complications.

> I don't like limits on how I use the stack and if the 
> programmer is an amateur is a weak argument. I really question 
> how effective this limit is. I rather go the VS route which 
> mean proper stack analysis in debug mode.

The «amateur» claim is 100% bogus and a made up excuse. There is 
nothing wrong with stack allocating buffers near the leafs on the 
callstack. When you know what the call depth is then allocating 
temporary buffers on the stack is a good, high performing 
strategy if the runtime and code-gen is sensible.

If you specify what your estimated worst case stack depth is, 
then you shouldn't hit the guard pages anyway. For a system level 
language the programmer should decide this, absolutely!