On Thursday, 22 January 2026 14:53:46 Pacific Standard Time Sebastian Wittmeier
via Std-Proposals wrote:
> If it is a trivially copyable variable stored on the stack,
>
> is there any guarantee that clear_padding creates code at all?

I think that's the wrong question to ask. Let's take the hypothetical example
of a popcount over a long double:

int popcount(long double f)
{
    std::clear_padding(f);
    return std::popcount(reinterpret_cast<uint128_t &>(f));
}

It doesn't *need* to emit code. In fact, I'd expect this to *suppress* code by
knowing that 6 of the 16 bytes are zero and thus don't contribute to the count
of bits set. The compiler should realise it only needs to popcount 8+2 bytes.

The important question is that of behaviour. So long as it behaves as if the
bits have been cleared, any as-if transformation is fine.

> Wouldn't an optimizer for each read after the clear_padding function use a
> copy with the padding bits unspecified again?
>
> And/or remove the clear_padding call?
>
> Is there any guarantee in the standard that padding bits are to be
> preserved, that they can be (re)set and are expected to stay that way until
> they are read?

That's a good question and may require text updates. In turn, that may require
some feedback from compiler vendors whether they currently have taken
liberties with this.

The important thing is that the storage for this type, whether concrete or
"as-if", must have had its bits cleared and must remain so until the next time
the variable is assigned to.

If you copy to another variable of the same type, all bets are lost. That
includes function calls where it is passed by value.

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