Date: Sat, 24 Jan 2026 00:38:19 +0300
On 23 Jan 2026 23:54, Sebastian Wittmeier via Std-Proposals wrote:
>> 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.
Yes. Or to put it another way, an operation must work on object
representation (rather than just value representation) in order to be
able to consume padding.
>> 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)
You can examine padding by copying the object representation to an array
of bytes using memcpy. Earlier in the discussion, I provided a code
sample that showed this, and that code demonstrates that the padding
cannot change out of thin air. That is, memcpy'ing from the object
representation multiple times, without modifying the object in between,
has to produce the same sequence of bytes every time. The bits that
correspond to padding will have unspecified values, but those values
must be the same every time.
>> 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.
Yes. Or to put it another way, an operation must work on object
representation (rather than just value representation) in order to be
able to consume padding.
>> 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)
You can examine padding by copying the object representation to an array
of bytes using memcpy. Earlier in the discussion, I provided a code
sample that showed this, and that code demonstrates that the padding
cannot change out of thin air. That is, memcpy'ing from the object
representation multiple times, without modifying the object in between,
has to produce the same sequence of bytes every time. The bits that
correspond to padding will have unspecified values, but those values
must be the same every time.
Received on 2026-01-23 21:38:22
