Struct packing and alignment with mingw

Question

I am emulating code from an embedded system (stm32, Keil µVision 5, MDK-ARM) on a PC (mingw32, 32bit arch). The alignment of the ARM compiler does not match my desktop mingw build:

// ARM Code (ARM compiler uses __packed)
typedef __packed struct _file
{
    uint8_t var1;
    uint16_t var2;
} FILE;

// PC mingw gcc code trying to emulate layout above.
typedef struct __attribute__((packed, aligned(1))) _file
{
    uint8_t var1;
    uint16_t var2;
} FILE;

In the source I do the following: file.var1 = 0x22; file.var2 = 0xAA55; which is then written to memory. When I read the memory on the embedded system it shows 0x22, 0x55, 0xAA. On the Windows machine it reads 0x22, 0xFF, 0x55, 0xAA, with padding at the 2^nd byte. How can I correct this behaviour?

Answer 1

I fixed it by myself -> Compiling with -mno-ms-bitfields helps! The code above is indeed correct. It is necessary to tell mingw to use gcc's bitfield organisation instead of the microsoft style. Though the code can be uncompileable with microsoft compilers then, I do not care at this point.

Answer 2

According to the GCC manual's examples, the attribute should go after the struct's fields, i.e.:

// PC Code
typedef struct
{
    uint8_t var1;
    uint16_t var2;
} __attribute__((packed, aligned(1))) FILE;

I also dropped the pointless struct tag (_file).

The above has a sizeof value of 3 when I tested it quickly.

Answer 3

attribute packed is broken on mingw32 compilers. Another option is to use pragma pack:

#pragma pack(1)
typedef struct _file
{
  uint8_t var1;
  uint16_t var2;
} FILE;

Answer 4

Why don't place struct elements in descending size order instead? You wouldn't need to worry about the padding byte.

// ARM Code
typedef struct _file
{
    uint16_t var2;
    uint8_t var1;
} FILE;

typedef struct _file
{
    uint16_t var2;
    uint8_t var1;
} FILE;