On Friday, 16 January 2026 07:17:40 Pacific Standard Time Jan Schultke via Std-
Proposals wrote:
> The reason is also that granting the implementation the freedom to not copy
> around padding bytes is an optimization opportunity, and relying on the
> values of padding bytes is a massive (security-critical) bug anyway. There
> are still floating-point types where certain representations result in CPU
> traps when used in an operation, if you find that to be more convincing of
> a reason.
>
...
> Because the source could also not be used. For all intents and purposes,
> padding bits are eternally indeterminate quantum bits, and querying their
> value results in your CPU exploding.
>
...
> It is doing god knows what. When a type has four value bytes and four
> padding bytes, moving it around may be done via 32-bit register move.
> Whether that preserves the upper 32 bits or wipes them (like on x86) is a
> CPU architecture implementation detail, and not anything you can portably
> rely on.

This is a long way of saying that

  template <typename T> T clear_padding(const T &);

isn't useful because the the padding bits can be come indeterminate again
before you can make use of the result, including passing to std::bit_cast.

That is, we require a way to clear *and* cast to a type that has no padding
bits in one operation. So we go back to either std::bit_cast_zero_padding or
modifying std::bit_cast behaviour.

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