Date: Fri, 23 Jan 2026 13:15:51 -0800
On Friday, 23 January 2026 12:54:30 Pacific Standard Time 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.
You can't access the padding bits of a type that has them, therefore you can't
tell whether they are indeterminate or not. It's meaningless to say they are
indeterminate: they are inaccessible.
Merely reading it should not cause the padding bits to change, though. If you
had accessed them via a byte array before, they must remain the same after
too.
> > 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)
See my other email.
I'm not sure I agree with Andrey's assertion that the padding bits cannot
change even for unmodified objects. It makes sense, but I don't think the
language guarantees that.
And I think I've found a case where GCC does not guarantee that.
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.
You can't access the padding bits of a type that has them, therefore you can't
tell whether they are indeterminate or not. It's meaningless to say they are
indeterminate: they are inaccessible.
Merely reading it should not cause the padding bits to change, though. If you
had accessed them via a byte array before, they must remain the same after
too.
> > 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)
See my other email.
I'm not sure I agree with Andrey's assertion that the padding bits cannot
change even for unmodified objects. It makes sense, but I don't think the
language guarantees that.
And I think I've found a case where GCC does not guarantee that.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-23 21:15:53
