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.

For example, we have not investigated why, but recent experience is that with
MSVC 64-bit on Windows, we are getting ~300 recursions in a 1 MB stack before
a stack overflow. That's a 3400 bytes per frame, which is way more than the
local variables in our code would seem to suggest, especially when the stack
overflow on Linux (granted, 8MB stacks) takes one or two more orders of
magnitude of recursion. With just this information, I'd guess the compiler has
inserted some stack canaries to detect and prevent ROP.

So if you make a reasonable estimate with one compiler, then run another and
the value is insufficient, is that an error?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.