在Linux（gcc）和Windows（mingw32 gcc）之间具有不同位域的结构的大小

Question

Similar question, but specific to packed structs: Why would the size of a packed structure be different on Linux and Windows when using gcc?

---

I'm building a shared library for Linux and Windows that needs to deal with well-structured data over a network connection. I'm using gcc 4.8.2 on Linux, and cross-compiling for Windows targets using i686-pc-mingw32-gcc 4.8.1.

I've made this little program to demonstrate the issue (note the GCC attributes are commented out, left them in for reference):

#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;
}

I'm compiling for Linux using: gcc -g -Wall test.c -o ./test

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

Very straightforward I thought. When run on Linux, the output is what I would expect:

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

But on Windows:

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

So what's the deal with the Windows sizes? Why are they different from Linux in this case?

---

I will eventually need to pack these enums and structs, but this issue appears before any packing is done. When enabled though, the results are similar:

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

Answer 1

The C specification has an informative annex (Annex J) that summarizes unspecified behavior, undefined behavior, and implementation defined behavior. Here's what it says about bit-fields.

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).

You can draw your own conclusions, but I would not use bit-fields in code that's intended to be portable.

---

It seems that on windows, the compiler starts a new "unit" every time the type changes. So in the unpacked case, you have a word_t (2 bytes) followed by a prio_t (4 bytes), a flag_t (4 bytes), and another word_t (2 bytes) for a total of 12 bytes. When packed it's 2,1,1,2 for a total of 6. If you declared all the fields as uint16_t, you'll probably get the correct size on windows, but you still have the problem of "the order of allocation of bit-fields within a unit" is implementation defined.