0
#include "stdio.h"

#pragma pack(8)
struct testSize {
    int a;  //size 4, alignment 8
    double b;//size 8, alignment 8
};
#pragma pack()

int main(int argc, char** argv)
{
    printf("sizeof testSize %d \n", sizeof(struct testSize));
    printf("sizeof int %d , sizeof double %d\n", sizeof(int), sizeof(double));

    return 0;
}

The default max alignment of a struct is 8, and also we can set by #pragma pack(8) or -fpack-struct=8. But on 32bit process compiled with gcc, it doesn't work.

On Linux (32): 

$ gcc -m32 -fpack-struct=8 -o TestSize TestSize.c
$ ./TestSize
sizeof testSize 12
sizeof int 4 , sizeof double 8

On VS (x86):

sizeof testSize 16
sizeof int 4 , sizeof double 8

On linux, the alignment seems like 4, not 8. From the doc, it's "For compatibility with Microsoft Windows compilers".

John Kugelman
  • 349,597
  • 67
  • 533
  • 578
George
  • 13
  • 2
  • 1
    [the result of `sizeof` must be printed using `%zu`](https://stackoverflow.com/q/940087/995714). Using the wrong format specifier [invokes UB](https://stackoverflow.com/q/16864552/995714) – phuclv Feb 01 '19 at 03:05

2 Answers2

2

The GCC page you link says the pragma "changes the maximum alignment". It could well be that the 8 bytes you specify is being ignored in favor of a smaller default of 4 on your compilation target.

(Packing pragmas are typically used when it's desirable to "pack tight", like to single-byte alignment, for structures that will travel over the wire or get persisted to disk in a program-agnostic sort of way. They're not generally used to enforce arbitrary alignments.)

Ben Zotto
  • 70,108
  • 23
  • 141
  • 204
  • from microsoft doc, the default value is 8, and 16 is also a valid value. this mean n should not be ignored by default value. Microsoft doc https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/2e70t5y1(v=vs.100) . However how to get the smaller default alignment value of gcc on 32/64 process. – George Feb 01 '19 at 05:40
0

The documentation and observed behavior of GCC are consistent with each other.

GCC Docs:

For compatibility with Microsoft Windows compilers, GCC supports a set of #pragma directives that change the maximum alignment of members of structures

[...]

#pragma pack(n) simply sets the new [maximum] alignment

The resulting size of the struct shows that GCC on Linux is aligning the double on a four-byte (or less) boundary. Four is less than 8.

The documentation and observed behavior of VS are consistent with each other.

VS Docs:

Specifies packing alignment for structure, union, and class members.

[...]

n [...] The alignment of a member will be on a boundary that is either a multiple of n or a multiple of the size of the member, whichever is smaller.

The size of a double is 8, and the specified maximum alignment is 8. The size of the structure shows that VS on Windows aligns the double on an 8-byte boundary, just as it should.

On linux, the alignment seems like 4, not 8. From the doc, it's "For compatibility with Microsoft Windows compilers".

Both compilers accept your pragma. It has no practical effect on either one. This is source compatibility with respect to the pragma.

That the default alignment rules for the two compilers differ could be taken as an incompatibility, but that's not an issue of the pragma. And in this case you can use the pragma to get the same (weaker) alignment of both structures by specifying maximum alignment 4. Or you should be able to get the stronger alignment with GCC on x86 Linux by via the -malign-double compiler option.

But note well that by looking at VS on Windows and GCC on Linux, you are comparing apples and oranges. There is no binary compatibility consideration across those platforms. Consider trying your experiment with a Windows build of GCC, such as MinGW's. I'm not in a position to test at the moment, but I anticipate that GCC on Windows will conform to Windows alignment conventions by default, and that pragma pack will affect the layout exactly the same way on the GCC/Windows as it does on VS/Windows.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157