c++g++language-lawyerclang++standard-layout

Standard-layout and tail padding

David Hollman recently tweeted the following example (which I've slightly reduced):

struct FooBeforeBase {
    double d;
    bool b[4];
};

struct FooBefore : FooBeforeBase {
    float value;
};

static_assert(sizeof(FooBefore) > 16);

//----------------------------------------------------

struct FooAfterBase {
protected:
    double d;
public:  
    bool b[4];
};

struct FooAfter : FooAfterBase {
    float value;
};

static_assert(sizeof(FooAfter) == 16);

You can examine the layout in clang on godbolt and see that the reason the size changed is that in FooBefore, the member value is placed at offset 16 (maintaining a full alignment of 8 from FooBeforeBase) whereas in FooAfter, the member value is placed at offset 12 (effectively using FooAfterBase's tail-padding).

It is clear to me that FooBeforeBase is standard-layout, but FooAfterBase is not (because its non-static data members do not all have the same access control, [class.prop]/3). But what is it about FooBeforeBase's being standard-layout that requires this respect of padding bytes?

Both gcc and clang reuse FooAfterBase's padding, ending up with sizeof(FooAfter) == 16. But MSVC does not, ending up with 24. Is there a required layout per the standard and, if not, why do gcc and clang do what they do?

There is some confusion, so just to clear up:

Solution

  • The answer to this question doesn't come from the standard but rather from the Itanium ABI (which is why gcc and clang have one behavior but msvc does something else). That ABI defines a layout, the relevant parts of which for the purposes of this question are:

    For purposes internal to the specification, we also specify:

    • dsize(O): the data size of an object, which is the size of O without tail padding.

    and

    We ignore tail padding for PODs because an early version of the standard did not allow us to use it for anything else and because it sometimes permits faster copying of the type.

    Where the placement of members other than virtual base classes is defined as:

    Start at offset dsize(C), incremented if necessary for alignment to nvalign(D) for base classes or to align(D) for data members. Place D at this offset unless [... not relevant ...].

    The term POD has disappeared from the C++ standard, but it means standard-layout and trivially copyable. In this question, FooBeforeBase is a POD. The Itanium ABI ignores tail padding - hence dsize(FooBeforeBase) is 16.

    But FooAfterBase is not a POD (it is trivially copyable, but it is not standard-layout). As a result, tail padding is not ignored, so dsize(FooAfterBase) is just 12, and the float can go right there.

    This has interesting consequences, as pointed out by Quuxplusone in a related answer, implementors also typically assume that tail padding isn't reused, which wreaks havoc on this example:

    #include <algorithm>
#include <stdio.h>

struct A {
    int m_a;
};

struct B : A {
    int m_b1;
    char m_b2;
};

struct C : B {
    short m_c;
};

int main() {
    C c1 { 1, 2, 3, 4 };
    B& b1 = c1;
    B b2 { 5, 6, 7 };

    printf("before operator=: %d\n", int(c1.m_c));  // 4
    b1 = b2;
    printf("after operator=: %d\n", int(c1.m_c));  // 4

    printf("before std::copy: %d\n", int(c1.m_c));  // 4
    std::copy(&b2, &b2 + 1, &b1);
    printf("after std::copy: %d\n", int(c1.m_c));  // 64, or 0, or anything but 4
}

    Here, = does the right thing (it does not override B's tail padding), but copy() has a library optimization that reduces to memmove() - which does not care about tail padding because it assumes it does not exist.