6.36.5 i386 Variable Attributes

Two attributes are currently defined for i386 configurations: ms_struct and gcc_struct

ms_struct

gcc_struct

If packed is used on a structure, or if bit-fields are used, it may be that the Microsoft ABI lays out the structure differently than the way GCC normally does. Particularly when moving packed data between functions compiled with GCC and the native Microsoft compiler (either via function call or as data in a file), it may be necessary to access either format.

Currently ‘-m[no-]ms-bitfields’ is provided for the Microsoft Windows X86 compilers to match the native Microsoft compiler.

The Microsoft structure layout algorithm is fairly simple with the exception of the bit-field packing. The padding and alignment of members of structures and whether a bit-field can straddle a storage-unit boundary are determine by these rules:

1. Structure members are stored sequentially in the order in which they are declared: the first member has the lowest memory address and the last member the highest.
2. Every data object has an alignment requirement. The alignment requirement for all data except structures, unions, and arrays is either the size of the object or the current packing size (specified with either the aligned attribute or the pack pragma), whichever is less. For structures, unions, and arrays, the alignment requirement is the largest alignment requirement of its members. Every object is allocated an offset so that:

   offset % alignment_requirement == 0
   

3. Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte allocation unit if the integral types are the same size and if the next bit-field fits into the current allocation unit without crossing the boundary imposed by the common alignment requirements of the bit-fields.

MSVC interprets zero-length bit-fields in the following ways:

1. If a zero-length bit-field is inserted between two bit-fields that are normally coalesced, the bit-fields are not coalesced.

   For example:

   struct
    {
      unsigned long bf_1 : 12;
      unsigned long : 0;
      unsigned long bf_2 : 12;
    } t1;
   

   The size of t1 is 8 bytes with the zero-length bit-field. If the zero-length bit-field were removed, t1’s size would be 4 bytes.

2. If a zero-length bit-field is inserted after a bit-field, foo, and the alignment of the zero-length bit-field is greater than the member that follows it, bar, bar is aligned as the type of the zero-length bit-field.

   For example:

   struct
    {
      char foo : 4;
      short : 0;
      char bar;
    } t2;
   
   struct
    {
      char foo : 4;
      short : 0;
      double bar;
    } t3;
   

   For t2, bar is placed at offset 2, rather than offset 1. Accordingly, the size of t2 is 4. For t3, the zero-length bit-field does not affect the alignment of bar or, as a result, the size of the structure.

   Taking this into account, it is important to note the following:

   1. If a zero-length bit-field follows a normal bit-field, the type of the zero-length bit-field may affect the alignment of the structure as whole. For example, t2 has a size of 4 bytes, since the zero-length bit-field follows a normal bit-field, and is of type short.
   2. Even if a zero-length bit-field is not followed by a normal bit-field, it may still affect the alignment of the structure:

      struct
       {
         char foo : 6;
         long : 0;
       } t4;
      

      Here, t4 takes up 4 bytes.

3. Zero-length bit-fields following non-bit-field members are ignored:

   struct
    {
      char foo;
      long : 0;
      char bar;
    } t5;
   

   Here, t5 takes up 2 bytes.

This document was generated on October 19, 2013 using texi2html 5.0.