solaris sparc 和 solaris x86 之间的结构体大小差异答案

【问题标题】：Struct size differences between solaris sparc and solaris x86solaris sparc 和 solaris x86 之间的结构体大小差异
【发布时间】：2011-01-19 13:39:07
【问题描述】：

我正在将我们的应用程序从 solaris sparc 移植到 solaris x86，我遇到了这两种架构之间结构的大小差异。例如; 我有一个像

这样的结构

typedef struct mystructS
{
  double a;
  double b;
  double c;
  double d;
  double e;
  double f;
  double g;
  double h;
  double aa;
  double ab;
  double ac;
  double ad;
  double ae;
  double af
  double ag;
  double ah;
  int ba;
  int bb;
  int bc;
  char ca[256];
} mystructT;

当我在 solaris X86 中写 sizeof(mystructT) 时，它返回 396

当我在 solaris SPARC 中写 sizeof(mystructT) 时，它返回 400

我只是好奇，为什么会发生这样的事情？

编辑：两个 Solaris 系统都是 32 位的。

【问题讨论】：

标签： c solaris sizeof

【解决方案1】：

无论出于何种原因（也许双打需要在 sparc 上对齐，而不是在 x86 上？）它似乎试图确保下一个结构在 64 位边界上对齐。

也就是说，为了让你在内存中跳转 sizeof(mystructT) 步骤并最终指向你的结构的开头（例如，当创建一个结构数组时，这就是你在遍历它），结构必须在最后填充。

【讨论】：

我可以确认 Sun CC 在 x86 上将 double 对齐到 4 字节边界，而在 Sparc 上将它们对齐到 8 字节边界。 FWIW，Linux 86 上的 gcc 将双精度对齐到 8 字节边界。
+1 在开始我自己的答案之前，我应该更仔细地阅读现有答案。
'offsetof(3)' from stddef.h 在这里也可以证明是有用的

【解决方案2】：

如果 SPARC 是 64 位，编译器可能会尝试在边界上对齐 ca，这意味着它会在 bc 和 ca 之间填充额外的 4 个字节。如果是这种情况，您可能会要求编译器打包结构，以便它不会添加填充字节，但是您如何告诉它这样做往往有点依赖于编译器。

【讨论】：

这没什么意义，字符永远不需要对齐。为什么 ca[0] 会对齐，而 ca[1] 永远不会对齐？

【解决方案3】：

由于结构成员填充和对齐始终是实现定义的，因此您永远不应该对结构的大小做出任何假设（即使在同一平台上同一编译器的不同版本之间，或具有不同优化设置的同一编译器之间）。

如果您需要特定的对齐和打包，您必须使用编译器特定的指令来实现这一点。这可能是通过命令行编译选项、#pragma 指令或在 GCC 和一些其他编译器 __attribute__ 规范中实现的。或者也许更健壮（但更多的工作）使用数据序列化。

【讨论】：

我并不认为该标准不能保证任何事情。不过，我从未见过在实现定义的行为上下文中讨论过优化选项，如果您有参考，我将不胜感激。从务实的角度来看，如果情况像你说的那样可怕，我们就不可能有 ABI。我的标准库的系统头文件中有结构定义，它们为系统 C 编译器的所有优化级别定义了相同的布局。
@Pascal：你可能是对的，没有那么糟糕；但是不同的系统有不同的 ABI，但是像这样写代码并没有什么坏处。即使在 x86 上，Linux 和 Windows ABI 之间以及 32 位和 64 位版本之间也存在差异。

【解决方案4】：

最有可能的是，alignof(double) 在一个编译器中为 8，而在另一个编译器中为 4。

结构体的对齐方式被编译为其字段对齐方式的最小公倍数，在这种特殊情况下，这意味着double 的对齐方式决定了struct mystructS 的对齐方式。

结构的大小必须是其对齐方式的倍数（这是为了让您在制作此类结构的数组时能够正常工作）。因此，结构对齐为 8 的编译器也必须通过在末尾添加填充来将大小四舍五入为 8 的倍数。

【讨论】：