The call stack in basically every programming environment is a virtual memory system with overcommit and allocation that never returns errors.
Conversation
Replying to
Only if you misuse it as such by performing the cursed operation known as recursion.
2
1
Linux kernel will also lazily map in the main thread stack even with overcommit disabled. Runtime has to do something about that during initialization if it wants to guarantee that a certain amount can be used later. An error can occur simply when you reach deepest stack usage.
2
1
i.e. read a byte from each page just past the desired limit and install an actual guard page/region rather than relying on the magical automatically growing guard region it usually provides. Only thing I have seen doing this is ART for reliably throwing stack overflow exception.
-fstack-clash-protection does the first bit — read a byte from each page. That's ensures SIGSEGV over UB.
If you have neither that nor proven static bounds on stack sizes, it seems unlikely a program logic can be sound; (with that it'd be sound up to stack overflows).
1
-fstack-clash-protection just prevents you from jumping over a guard page/region. It doesn't map in the whole stack before you start using it. It doesn't prevent dying because of memory allocation failure with overcommit disabled when you call a function because mapping fails.
1
1
Show replies