Date: Fri, 23 Jan 2026 23:23:42 +0300
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';
}
> 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';
}
Received on 2026-01-23 20:23:45
