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.
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.
1
1
-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
Show replies
That's only for growth beyond the initially committed size, which is a hard coded 128k.
1
It's usually configured to allow 8M though (default since 1995) so programs have grown to rely on being able to put 16k-64k buffers and tons of other data on the stack. It's treated as best practice for performance and it does make a lot of sense. Can avoid the dynamic errors.
1
Show replies