[basic.types.general] p4 The effect of "padding bits" is underspecified

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[basic.types.general] p4 says:

Bits in the object representation of a type or object that are not part of the value representation are padding bits.

This is the only definition of padding bits, however, there is no wording to introduce what padding bits do. The only potential part introducting what it does is implied in [expr.new] p18

plus any padding necessary to align the allocated objects within the allocated memory.

[jensmaurer]

See [basic.fundamental] p4. Padding bits in an integer cause alternative, valid object representations for a given value.

That seems a sufficient use of the definition of "padding bits" to be responsive to the issue raised.

[xmh0511]

@jensmaurer

Padding bits in an integer cause alternative, valid object representations for a given value.

This is about fundamention type. We do not have the wording about what "padding bits" do in user-defined type, such as class. The whole clause [class] just have a note that explain why class needs "padding bits"

[Note 11: There can therefore be unnamed padding within a standard-layout struct object inserted by an implementation, but not at its beginning, as necessary to achieve appropriate alignment. — end note]

This is not a formal wording.

[jensmaurer]

Well, the bit_cast wording does talk about padding bits and its effects, and it's also applicable for class types. Beyond looking at the object representation, I don't think you can observe padding bits via other means. If you believe more specification is needed, please show an example that might change behavior.

[xmh0511]

If you believe more specification is needed, please show an example that might change behavior.

#include <iostream>
#include <cstddef>
struct A{
    int i;
    char b;
    int k;
};
int main(){
    auto o = offsetof(A,b);
    auto o1 = offsetof(A,k);
    std::cout<<(o1 - o);
}

The output is 4. That is, there are some bits between A::b and A::k since the sizeof(char) is 1.

[jensmaurer]

"The output is 4" is not a universal truth, it just happens to be so on your platform. And we know that struct layout is implementation-defined. What exactly is the specification problem you seem to highlight here?

[xmh0511]

What exactly is the specification problem you seem to highlight here?

I mean one purpose of padding bits is to insert them into class such that the address of the storage of its subobject satisfies the requirement of the object type.

Even though the alignment requirement and size of a type are implementation-defined, once the standard imposes an alignment requirement on the non-static data member object, the implementation must insert the padding bits to satisfy the requirement, if necessary. however, the standard does not explicitly inhibit the implementation of inserting the padding bits, or permit the implementation of inserting padding bits.