类似的问题，但特定于打包结构: Why would the size of a packed structure be different on Linux and Windows when using gcc?

我正在为 Linux 和 Windows 构建一个共享库，它需要通过网络连接处理结构良好的数据。我在 Linux 上使用 gcc 4.8.2，并使用 i686-pc-mingw32-gcc 4.8.1 为 Windows 目标交叉编译。

我制作了这个小程序来演示这个问题(请注意 GCC 属性已被注释掉，保留它们以供引用):

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

typedef uint16_t word_t;

typedef enum //__attribute__((__packed__))
{
  PRIO_0 = 0,
  PRIO_1,
  PRIO_2,
  PRIO_3,
  PRIO_4,
  PRIO_5,
  PRIO_6,
  PRIO_7,
}
prio_t;

typedef enum //__attribute__((__packed__))
{
  FLAG_A = 0,
  FLAG_B,
}
flag_t;

typedef struct //__attribute__((__packed__))
{
  word_t id     : 8;
  prio_t prio   : 3;
  flag_t flag_1 : 1;
  flag_t flag_2 : 1;
  flag_t flag_3 : 1;
  flag_t flag_4 : 1;
  word_t spare  : 1;
}
recd_t;


int main(int argc, char *argv[])
{
#define NAME_WIDTH 32

  printf("%-*s = %lu\n", NAME_WIDTH, "sizeof(prio_t)", (unsigned long)sizeof(prio_t));
  printf("%-*s = %lu\n", NAME_WIDTH, "sizeof(flag_t)", (unsigned long)sizeof(flag_t));
  printf("%-*s = %lu\n", NAME_WIDTH, "sizeof(recd_t)", (unsigned long)sizeof(recd_t));

  return 0;
}

我正在为 Linux 编译使用: gcc -g -Wall test.c -o ./test

和Windows: i686-pc-mingw32-gcc -g -Wall test.c -o ./test.exe

我觉得很简单。在 Linux 上运行时，输出是我所期望的:

sizeof(prio_t)                   = 4
sizeof(flag_t)                   = 4
sizeof(recd_t)                   = 4

但是在 Windows 上:

sizeof(prio_t)                   = 4
sizeof(flag_t)                   = 4
sizeof(recd_t)                   = 12

那么 Windows 大小有什么关系呢？为什么在这种情况下它们与 Linux 不同？

我最终需要打包这些枚举和结构，但这个问题在任何打包完成之前就出现了。但是，启用后，结果是相似的:

Linux:

sizeof(prio_t)                   = 1
sizeof(flag_t)                   = 1
sizeof(recd_t)                   = 2

Windows :

sizeof(prio_t)                   = 1
sizeof(flag_t)                   = 1
sizeof(recd_t)                   = 6

最佳答案

C 规范有一个信息性附件 (Annex J)，它总结了未指定的行为、未定义的行为和实现定义的行为。这是关于位域的内容。

J.3 Implementation-defined behavior

A conforming implementation is required to document its choice of behavior in each of the areas listed in this subclause. The following are implementation-defined:

J.3.9 Structures, unions, enumerations, and bit-fields

• Whether a "plain" int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).

• Allowable bit-field types other than _Bool, signed int, and unsigned int (6.7.2.1).

• Whether atomic types are permitted for bit-fields (6.7.2.1).
• Whether a bit-field can straddle a storage-unit boundary (6.7.2.1).
• The order of allocation of bit-fields within a unit (6.7.2.1).
• The alignment of non-bit-field members of structures (6.7.2.1). This should present no problem unless binary data written by one implementation is read by another.
• The integer type compatible with each enumerated type (6.7.2.2).

您可以得出自己的结论，但我不会在可移植的代码中使用位域。

似乎在 Windows 上，每次类型更改时，编译器都会启动一个新的“单元”。因此，在未打包的情况下，您有一个 word_t(2 个字节)，然后是一个 prio_t(4 个字节)、一个 flag_t(4 个字节)和另一个 word_t(2 个字节)，总共 12 个字节。打包后为 2,1,1,2，总共 6 个。如果您将所有字段声明为 uint16_t，您可能会在 Windows 上获得正确的大小，但您仍然有 “顺序的问题单元内位域的分配” 是实现定义的。

关于c - Linux (gcc) 和 Windows (mingw32 gcc) 之间具有不同位域的结构大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31349819/