2 ms·
As mentioned in the OP though, there is zero guarantee about the stack usage by library functions.
by lifthrasiir 5y ago
As mentioned in the OP though, there is zero guarantee about the stack usage by library functions.
- OskarS 5y agoNo, but that's a pretty weak argument not to have them: they're better than nothing. Not all code uses libraries. And if it was part of the C standard, libraries could use them as well: libraries could fail gracefully instead of blowing the stack. Many libraries already do this when malloc fails, after all.
- saagarjha 5y agoI have yet to see a library that fails gracefully when malloc fails. Many claim to be able to do so, but usually keel over when actually presented with a failure.
- PerkinWarwick 5y ago...or much of anything else. I've seen commercial libraries monkey with processor state in some nasty ways.
- nybble41 5y agoThere is also no guarantee that the stack is contiguous—see the "-fsplit-stack" GCC option, or search for "segmented stacks". Libraries for coroutines and delimited continuations also routinely segment the stack. A simple API based around easy access to "top of stack", "bottom of stack", and "current stack pointer" addresses is thus non-universal. There may not be a meaningful limit to the amount of stack available, aside from available heap memory or address space. And this can change over time in response to actions other than allocating or freeing memory on the stack.