Compartilhar via


Structure Packing

Posted by: Russ Keldorph

Structure packing is an extenstion to the C++ language supported by many compilers, including Microsoft's.  In our language, packing is achieved with either  #pragma pack(N) , which allows fine-grained control over structure packing, or the -ZpN compiler switch, which is equivalent to adding #pragma pack(N) to the beginning of a translation unit.

Microsoft's packing semantics are best explained in the greater context of alignment, so that's how I'll attempt it.

#pragma pack(N)  places a limit of N on the alignment of structure members relative to the beginning of their parent structure.  The packing alignment can be changed at any point during a structure's definition so that some members can have a different limit than others within the same structure.

The formal alignment rules are:

  1. The natural alignment (NA) of a scalar data type (char, int, double, etc.) is its size.
  2. The natural alignment of an aggregate data type (array or struct) is the alignment (A) of its member(s) with the most restrictive (greatest) alignment.
  3. If a scalar member is declared with a __declspec(align(#)) modifier or is of a type declared with such a modifier, it is subject to a restricted alignment (DA) specified by the most restrictive (largest) of said modifiers (#).  Similarly, if an aggregate member is declared with a __declspec(align(#)) modifer, is of a type declared with __declspec(align(#)), or contains a member subject to a restricted alignment, then it is subject to the most restrictive of said restricted alignments, including those specified by a top level modifier, if any.
  4. The alignment of a structure member (scalar or aggregate) is the minimum of its natural alignment and the current packing alignment (PA) unless the member is subject to a restricted alignment.  It that case, the restricted alignment sets a minimum alignment, i.e. A = max(DA, min(NA, PA)).
  5. The offset of the first member from the beginning of its parent structure is zero (0).
  6. The offset of the second and each subsequent member from the beginning of its parent structure is the smallest multiple of its alignment greater than or equal to the offset of the end of the previous member.  Padding is inserted before the member if necessary.
  7. The size of an aggregate data type is the smallest multiple of its alignment greater than or equal to the offset of the end of its last member.  Padding is appended after the last member if necessary.

Note the distiction between natural alignment and alignmentNatural alignment is an attribute of a type, but the actual alignment of a piece of data is affected by more than its type.  Also note that packing can cause data to become misaligned, i.e not naturally aligned.  Compilers have to be very careful about alignment if packing is involved because some processors cannot deal with misaligned data in the same way they deal with naturally aligned data.  My next post will cover that topic in more detail.

Also note that these rules only apply to C types or C++ POD types.  Other types may be subject to other layout rules that you should not rely on under any circumstances.

Since I'd like to keep this post as short as possible, I'll leave examples up to the reader.  I encourage you to post sample structures and use the rules to predict the alignment and offsets of members and the structures themselves.

[Update: Rule 3 inserted and rule 4 (formerly 3) modified to clarify ambiguity around __declspec(align(#)); added caveat of applicability to PODs only.]

Comments

  • Anonymous
    April 14, 2006
    For more information and some examples of packing, see:

    http://msdn2.microsoft.com/en-us/library/2e70t5y1(VS.80).aspx
    http://msdn2.microsoft.com/en-us/library/ms253935(VS.80).aspx
  • Anonymous
    April 29, 2006
    Does compiler generate code to took care of alignment for packed records?ie is it always safe to use them directly without unalignedment decleration...
    and what it does if they are pointers?
  • Anonymous
    May 02, 2006
    Yes, the compiler will generate code appropriate to access misaligned fields in packed structures if the member is accesses via a pointer to the parent structure.  The __unaligned modifier is not necessary.  Note, however, that if you assign the address of a field in a packed structure to a normal pointer, the compiler will generate code assuming the pointed-to data is aligned.  For example:

    #pragma pack(1)
    struct S {
     char c;
     int i;
    };
    int get_i(struct S* ps) {
     int* p = &ps->i;
     return *p; // datatype misalignment
    }

    In this case, the __unaligned modifier is necessary to tell the compiler to generate alignment-neutral code on some platforms.  Declare the pointer p like this:

     int __unaligned * p = &ps->i;

    Note that the IA-32 (x86) compiler does not support the __unaligned keyword as it would be ignored anyway.