On 12/13/21 4:44 AM, Bo Persson wrote:
> On 2021-12-13 at 06:48, Juha Nieminen wrote:
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> No. Stack overflow is arguably the least specified behavior of them all.
>>> The stack size is extremely limited (few MB), compared to the RAM
>>> amounts current computers have (tens of GB). There is no
>>> standard-defined way to detect stack overflow, not to speak about
>>> handling it.
>>
>> That made me think: Why has neither the C nor the C++ standardization
>> committees ever thought of adding a standard library utility to get
>> the current amount of free stack space?

A key factor in that decision is the fact that neither the C nor the C++
standard ever talks about the stack space, a fact that allows either
language to be implemented on systems where the concept of "stack" is
meaningless.
On operating systems where the concept is meaningful, there often is a
way to conduct such a query. For instance, on Unix-like systems, there's
getrlimit(RLIMIT_STACK, &rlim).

,,,
>> (In fact, getting the amount of free (physical) RAM available to the
>> process could also be useful, for similar reasons. It could behave
>> in the same way: -1 if the operation is for some reason not supported,
>> else the amount of free RAM (not counting swap).)
>
> This would be of very limited use. The result of a call from one thread
> wouldn't be valid long, if the other threads allocate and free memory
> already while the result is returned.
>
> It is similar to filesystem::exists("path"). If you get a true or false
> back, how long is the result valid? Nanoseconds?

There's an important difference: as a matter of the policies you use for
managing a filesystem (rather than anything enforced by the operating
system), it is not only possible, but commonplace, to be certain that a
given file, if present, will remain in existence long enough to do
whatever it is you want to do with it.
That's not the case with the amount of free stack space.