我正在将我们的应用程序从solaris sparc移植到solaris x86，我在这两种架构之间遇到了struct的大小差异。例如; 我有一个像
这样的结构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位。答案 0 :(得分：4)
无论出于何种原因（可能需要在sparc上对齐双倍而不是在x86上对齐？），它似乎正在尝试确保下一个结构在64位边界上对齐。
也就是说，为了让你在内存中跳转sizeof（mystructT）步骤并最终指向结构的开头（例如，在创建结构数组时，这就是你在做什么时所做的迭代它），结构必须在最后填充。
答案 1 :(得分：2)
如果SPARC是64位，编译器可能会尝试在边界上对齐ca，这意味着它将在bc和ca之间填充额外的4个字节。如果是这种情况，你可能会要求编译器打包结构，这样它就不会添加填充字节，但是如何告诉它这样做往往与编译器有关。
答案 2 :(得分：0)
由于结构成员填充和对齐始终是实现定义的，因此您不应对结构的sizof做任何假设（即使在同一平台上的同一编译器的不同版本之间，或者具有不同优化设置的相同编译器之间）。 / p>
如果需要特定的对齐和打包，则必须使用编译器特定的指令来实现此目的。这可以通过命令行编译选项#pragma指令或GCC和其他一些编译器__attribute__规范来实现。或者更强大（但更多的工作）使用数据序列化。
答案 3 :(得分：0)
最有可能的是，alignof(double)在一个编译器中为8，在另一个编译器中为4。
结构的对齐被编译为其字段对齐的最小公倍数，在这种特殊情况下，它意味着double的对齐决定struct mystructS的对齐。
结构的大小必须是其对齐的倍数（如果你创建了这样一个结构的数组，这是为了使事情顺利运行）。因此，结构对齐为8的编译器必须通过在末尾添加填充来将大小舍入为8的倍数。