3

Consider:

struct empty {};
struct child : empty {
    empty a[sizeof(int) / sizeof(empty)];
    int b;
};
// Assume sizeof(int) >= sizeof(empty)

Does the standard mandate that sizeof(child) is more than 2 * sizeof(int)?

The way I see it, nothing prohibits the baseclass-subobject from sharing its address with member b.

If not, are there any common ABIs exploiting that at all?

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
  • 1
    Well, with GCC 4.8.4 I get `sizeof(child) == 8` while `sizeof(empty) == 1`. `sizeof(int) == 4` in this environment. Does this answer your question? – iehrlich Jul 04 '17 at 22:36
  • 1
    @iehrlich: No, as GCC 7.1.0 gives me the sizes 1, 4, and 12, which might hint as a fix, or just a different ABI: http://coliru.stacked-crooked.com/a/502ee91a75a65450 – Deduplicator Jul 04 '17 at 22:42
  • This might be relevant: http://en.cppreference.com/w/cpp/language/ebo – icktoofay Jul 04 '17 at 22:42
  • @icktoofay: That's not the standard, and what's described does not actually satisfy "two different objects of same type must have different addresses". – Deduplicator Jul 04 '17 at 22:44
  • Interesting: In C++14, `child` is a standard layout type, but this looks like an accident that has since been fixed for the C++17 draft. – aschepler Jul 04 '17 at 22:44
  • Related: https://stackoverflow.com/questions/2362097/why-is-the-size-of-an-empty-class-in-c-not-zero https://stackoverflow.com/questions/621616/c-what-is-the-size-of-an-object-of-an-empty-class https://stackoverflow.com/questions/9157118/c-class-empty-class-size-1-byte – Jerry Jeremiah Jul 04 '17 at 22:47
  • 2
    The issue/fix: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2120 – aschepler Jul 04 '17 at 23:14
  • 3
    Is this "EBO day" or something? – T.C. Jul 04 '17 at 23:16
  • 1
    @T.C. Yes, that's the theme. – Deduplicator Jul 04 '17 at 23:20

2 Answers2

4

Let us first check the rule that allows empty base class optimization to acquaint ourselves with the terminology:

N4659 standard draft [intro.object]

7 Unless it is a bit-field (12.2.4), a most derived object shall have a nonzero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size. [snip]

Then a requirement about distinct addresses:

8 Unless an object is a bit-field or a base class subobject of zero size, the address of that object is the address of the first byte it occupies. Two objects a and b with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a base class subobject of zero size and they are of different types; otherwise, they have distinct addresses.

The empty base subobject and the first element of the member array may not have the same address because they are of same type.

Therefore, if we assume that the base subobject must be ordered before the members and that the members must be in declaration order, padding is required to achieve distinct addresses. However, I cannot find a rule in the standard that would require such order.

The portable Itanium C++ ABI (used by Clang and GCC) does specify the order, and under that specification, padding is indeed required:

2.4 Non-POD Class Types

II. Allocation of Members Other Than Virtual Bases

For each data component D (first the primary base of C, if any, then the non-primary, non-virtual direct base classes in declaration order, then the non-static data members and unnamed bitfields in declaration order), allocate as follows:

A different ABI might be able to exploit EBCO here, if it allows non-declaration order sub-objects or member subobjects before bases in the memory layout. At least as a special case with empty bases. I don't know if such ABI exist.

Community
  • 1
  • 1
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • @Deduplicator I could not find a rule in the standard that would prohibit sharing the memory address of `b` for the base. So, EBCO might be exploitable as far as the standard is concerned. – eerorika Jul 04 '17 at 23:52
2

Is it possible from the specification? Yes. [class.mem]/24 tells us about the relationship between the address of a standard layout class and its first base class subobject. But the standard makes no statement about this relationship for non-standard layout types. And since your type is not standard layout, the standard says nothing about that location.

There are generally two ABI forms for base class assignment: put them before the members or put them after the members (for non-standard layout types). ABIs that assign base classes after the members would be free to assign empty base classes the last valid address with an appropriate alignment in the class's region of storage. If that happens to land in such a way as to avoid violating [intro.object]/8 (unique identity of subobjects), then it can perform that assignment.

The two most common ABIs, Windows and Itanium, both assign base classes before members. While such ABIs could assign base classes more arbitrarily, they don't bother doing that. This would only ever come up in template code anyway, since empty classes are empty. They all behave the same, so there's no reason to deliberately make them both a base class and a member.

So why bother having complex ABI rules for a case that is so rare?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982