I professionally do a lot of programming in the Nvidia Cuda ecosystem.   On that platform there is manually indexed scratch and data exchange space (shared memory), temporary data with (compile-time) fixed indices (huge register file) and everything going beyond in a stack-like or indexable fashion (local memory).   When compiling a function one can limit the number of registers and the amount of shared memory used and can see, whether local memory is needed at all (and how much).   So at least for some C++ compilers and target platforms statically checking the needed stack memory is already done.   -----Ursprüngliche Nachricht----- Von:Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 09.06.2026 17:38 Betreff:Re: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++ An:std-proposals_at_[hidden]; CC:Rainer Deyke <rainerd_at_[hidden]>; On 6/9/26 16:29, Thiago Macieira via Std-Proposals wrote: > On Tuesday, 9 June 2026 04:44:17 Pacific Daylight Time Rainer Deyke via Std- > Proposals wrote: >> Assuming a halfway competent optimizer, it uses up to somewhat more than >> 512 bytes.  The call to 'g' is inlined and optimized away and the 'buf' >> variable is optimized away, so we're left with the call to 'h', which is >> declared to take 512 bytes, plus the non-zero stack space used by the >> function call itself.  It is not possible to know how much stack space a >> function actually uses in a portable manner just by looking at it, but >> it's possible for the compiler to verify an upper limit to stack usage >> in some cases. > > I don't think you can estimate the stack usage in a portable manner with any > precision. You'll have to make a massive overestimation. I completely agree.  In fact, you'll end up with massive overestimation even if you limit yourself to a specific compiler and specific compiler settings for all but the most trivial functions, because the function arguments and the execution environment can have massive effects on the amount of stack space a function uses. But sometimes a massive overestimation is acceptable because provable correctness is more important that efficiency.  Same with programs that avoid dynamic memory allocation: horrible for efficiency (because all memory is allocated at program start and never released), but provably safe within its limits. > So if you make a reasonable estimate with one compiler, then run another and > the value is insufficient, is that an error? There are two possible, contradictory meanings to a manually provided stack size limit for a function:   - I require this function to be within this limit.  The compiler should check for me that this is the case, and fail hard when it cannot verify that the limit is correct.   - I know better than the compiler, and I have verified that the function is within this limit (for this specific compiler and these specific compiler settings). The former sounds far more useful to me than the latter, but it's possible to have both by adding an attribute that turns the checking off. -- Rainer Deyke - rainerd_at_[hidden] -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals