扩展填充结构时，为什么不能在尾部填充中放置额外的字段？

Question

让我们考虑结构：

struct S1 {
    int a;
    char b;
};

struct S2 {
    struct S1 s;       /* struct needed to make this compile as C without typedef */
    char c;
};

// For the C++ fans
struct S3 : S1 {
    char c;
};

S1 的大小为 8，由于对齐，这是预期的。但是 S2 和 S3 的大小是 12。这意味着编译器将它们构造为：

| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11|
|       a       | b |  padding  | c |  padding  |

编译器可以在不破坏对齐约束的情况下将 c 放在 6 7 8 的填充中。阻止它的规则是什么，背后的原因是什么？

Answer 1

简答（针对问题的 C++ 部分）：出于历史原因，Itanium ABI for C++ 禁止使用 POD 类型的基本子对象的尾部填充.请注意，C++11 没有这样的禁令。允许通过底层表示复制普通可复制类型的相关规则 3.9/2 明确排除了基本子对象。

---

长答案：我将尝试同时处理 C++11 和 C。

1. S1 的布局必须包含填充，因为S1::a 必须与int 对齐，并且数组S1[N] 由S1 类型的连续分配对象组成，每个a 成员必须保持一致。
2. 在 C++ 中，不是基本子对象的普通可复制类型 T 的对象可以被视为 sizeof(T) 字节的数组（即，您可以将对象指针强制转换为 unsigned char * 并将结果视为指向unsigned char[sizeof(T)] 的第一个元素的指针，这个数组的值决定了对象）。由于 C 中的所有对象都属于这种类型，这就解释了 C 和 C++ 的 S2。
3. C++ 剩下的有趣案例是：
   1. 不受上述规则约束的基础子对象（参见 C++11 3.9/2），以及
   2. 任何非普通可复制类型的对象。

对于 3.1，确实存在常见的流行“基本布局优化”，其中编译器将类的数据成员“压缩”到基本子对象中。这在基类为空时最为显着（减小了 ∞% 的大小！），但应用更广泛。但是，当相应的基本类型为 POD（并且 POD 表示可简单复制和标准布局）时，我在上面链接的 Itanium ABI for C++ 以及许多编译器实现的 Itanium ABI 禁止这种尾部填充压缩。

对于 3.2，Itanium ABI 的相同部分适用，尽管我目前不认为 C++11 标准实际上要求任意、非平凡可复制的 member 对象必须具有与同一类型的完整对象大小相同。

---

保留以前的答案以供参考。

我相信这是因为S1 是标准布局，因此出于某种原因S3 的S1-子对象保持不变。我不确定这是否是标准规定的。

但是，如果我们将S1 转换为非标准布局，我们会观察到布局优化：

struct EB { };

struct S1 : EB {   // not standard-layout
    EB eb;
    int a;
    char b;
};

struct S3 : S1 {
    char c;
};

现在sizeof(S1) == sizeof(S3) == 12 在我的平台上。 Live demo.

这是simpler example：

struct S1 {
private:
    int a;
public:
    char b;
};

struct S3 : S1 {
    char c;
};

混合访问使S1 非标准布局。 （现在sizeof(S1) == sizeof(S3) == 8。）

更新：定义因素似乎是琐碎以及标准布局，即类必须是 POD。以下非 POD 标准布局类可进行基本布局优化：

struct S1 {
    ~S1(){}
    int a;
    char b;
};

struct S3 : S1 {
    char c;
};

再次sizeof(S1) == sizeof(S3) == 8。 Demo

Answer 2

让我们考虑一些代码：

struct S1 {
    int a;
    char b;
};

struct S2 {
    S1 s;
    char c;
};

让我们考虑一下如果sizeof(S1) == 8 和sizeof(S2) == 8 会发生什么。

struct S2 s2;
struct S1 *s1 = &(s2.s);
memset(s1, 0, sizeof(*s1));

您现在已经覆盖了S2::c。

---

出于数组对齐的原因，S2 的大小也不能为 9、10 或 11。因此下一个有效大小是 12。

Answer 3

以下是编译器无法将成员 c 放置在 struct S1 成员 s 的尾随填充中的几个示例。假设编译器确实将struct S2.c 放在struct S1.s. 成员的填充中：

struct S1 {
    int a;
    char b;
};

struct S2 {
    struct S1 s;       /* struct needed to make this compile as C without typedef */
    char c;
};

// ...

struct S1 foo = { 10, 'a' };
struct S2 bar = {{ 20, 'b'}, 'c' };

bar.s = foo;    // this will likely corrupt bar.c

memcpy(&bar.s, &foo, sizeof(bar.s));    // this will certainly corrupt bar.c

bar.s.b = 'z';  // this is permited to corrupt bar by C99 6.2.6.1/6

C99/C11 6.2.6.1/6（“类型/一般表示”）说：

当一个值存储在结构或联合类型的对象中时， 包括在成员对象中，对象表示的字节 对应于任何填充字节的值采用未指定的值。

Answer 4

结构中的额外填充背后的原因是什么？

如果处理器对 alignment 很认真，它会引发异常/信号，否则会因为未对齐减慢数据访问而导致性能损失。

要理解这一点，让我们从data structure alignment开始：

数据结构对齐是数据在计算机内存中排列和访问的方式。它由两个独立但相关的问题组成：数据对齐和数据结构填充。当现代计算机读取或写入内存地址时，它将以字大小的块（例如 32 位系统上的 4 字节块）或更大的形式执行此操作。 数据对齐意味着将数据放置在等于字大小的某个倍数的内存偏移处，由于 CPU 处理内存的方式，这会提高系统的性能。为了对齐数据，可能需要在最后一个数据结构的结尾和下一个数据结构的开头之间插入一些无意义的字节，这就是数据结构填充。

例如，当计算机的字长为 4 字节时（一个字节在大多数机器上表示 8 位，但在某些系统上可能不同），要读取的数据应位于内存偏移量为 4 的某个倍数. 如果不是这种情况，例如数据从14th 字节而不是16th 字节开始，然后计算机必须读取两个 4 字节块并在读取请求的数据之前进行一些计算，否则可能会产生对齐错误强>。即使前一个数据结构在第 13 个字节结束，下一个数据结构也应该从第 16 个字节开始。在两个数据结构之间插入两个填充字节，以将下一个数据结构与第 16 个字节对齐。

---

扩展填充结构时，为什么不能在尾部填充中放置额外的字段？

编译器可以在不破坏对齐约束的情况下将 c 放在 6 7 8 的填充中。阻止它的规则是什么，背后的原因是什么？

编译器可以将它放在那里，但是对c 的内存访问会被误用¹，并且会产生性能损失，如上所述。要处理数组：

struct __attribute__((__packed__)) mypackedstruct{
    char a;
    int b;
    char c;
};  

此结构在 32 位系统上的编译大小为 6 字节。
在允许它的架构（如 x86 和 amd64）上，未对齐的内存访问速度较慢，并且在 SPARC 等严格对齐的架构上被明确禁止。

---

_{1 当被访问的数据为n 字节长（其中n 是2 的幂）且数据地址为n 时，内存访问称为对齐-字节对齐。当内存访问未对齐时，称为未对齐。}