Date: Tue, 9 Jun 2026 17:38:03 +0200
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.
> 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]
Received on 2026-06-09 15:38:15
