> Reading the value does not modify padding

But if you read as the type with padding, the read value has indeterminate padding bits. To actually read the padding you have to read as bytes or (unsigned) chars.

> This is not correct. The language already does not define padding as
> volatile, i.e. it does not say that the padding bits may change their
> value "at any time".

True, but under C++ up to C++26, if you could not clear and read back padding bits, they could have changed their value "at any time" under the as-if rule. Perhaps it was/is possible to create code, with which this does not happen (=accessing as bytes)
 

-----Ursprüngliche Nachricht-----
Von: Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Fr 23.01.2026 21:23
Betreff: Re: [std-proposals] Fixing std::bit_cast padding bit issues
An: std-proposals@lists.isocpp.org;
CC: Andrey Semashev <andrey.semashev@gmail.com>;
On 23 Jan 2026 21:02, Sebastian Wittmeier via Std-Proposals wrote:
> I am trying to summarize:
>
> So you define that
>
> std::clear_padding(T& t)
>
> would act on the lvalue t. t (as a lvalue) has a defined address in memory.
>
> All the padding bits/bytes are zeroed. Any access to the underlying
> storage (e.g. as std::byte or unsigned char) would read the zeroes.
>
> Any direct read or write of type T would still have or create
> indeterminate padding bits and bytes.

Reading the value does not modify padding. But creating a copy of the
object does not necessarily copy padding bits from the source. That is,
in the newly created object padding bits are not necessarily zeroed.

Writing may modify padding.

> Using t as a reference parameter would keep the cleared padding bits,
> using it as a value parameter not in the general case.
>
> Returning t as a value would neither keep the padding bits, one
> exception could have been in theory RVO, but there is no RVO facility in
> the language, where the value to be returned can be accessed as a lvalue.

Yes to the above.

> The language in general may not insert (anymore) any code changing the
> padding bits and bytes, if there was no write of t. This could have been
> possible up till now under the as-if rule, as the padding bits may have
> changed at any time.
This is not correct. The language already does not define padding as
volatile, i.e. it does not say that the padding bits may change their
value "at any time". At most, padding bits may change as a side effect
of some operation on the object. But even that has restrictions as the
bits that are viewed as padding in one context may actually be used as
value representation in potentially overlapping objects in another. For
example:

 struct Base
 {
   int n;
   char c;
   // padding

   virtual ~Base() = default; // non-standard layout class
 };

 struct Derived : Base
 {
   char d; // placed in the tail padding of Base
 };

 void foo(Base& b)
 {
   // none of the following may modify the padding
   // in b as b may be referring to an object
   // of type Derived, which also has the d member
   b.n = 10;
   b.c = 'x';
 }

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals