GCC 对 #pragma pack(N)和__attribute__((packed)) 的支持问题

GCC 对 #pragma pack(N) 的支持问题 

#pragma pack
这里重点讨论内存对齐的问题和#pragma pack（）的使用方法。
什么是内存对齐？
先看下面的结构：（结构体对齐原则：结构体所占字节总数是其最大类型字节数的整数倍）
struct TestStruct1
{
char c1;
short s;
char c2;
int i;
};
假设这个结构的成员在内存中是紧凑排列的，假设c1 的地址是0，那么s 的地址就应该
是1，c2 的地址就是3，i 的地址就是4。也就是c1 地址为00000000, s 地址为00000001, c2
地址为00000003, i 地址为00000004。
可是，我们在Visual C++6.0 中写一个简单的程序：
struct TestStruct1 a;
printf("c1 %p, s %p, c2 %p, i %p\n",
(unsigned int)(void*)&a.c1 - (unsigned int)(void*)&a,
(unsigned int)(void*)&a.s - (unsigned int)(void*)&a,
(unsigned int)(void*)&a.c2 - (unsigned int)(void*)&a,
(unsigned int)(void*)&a.i - (unsigned int)(void*)&a);
运行，输出：
c1 00000000, s 00000002, c2 00000004, i 00000008。
为什么会这样？这就是内存对齐而导致的问题。
3.6.8.1，为什么会有内存对齐？
字，双字，和四字在自然边界上不需要在内存中对齐。（对字，双字，和四字来说，自
然边界分别是偶数地址，可以被4 整除的地址，和可以被8 整除的地址。）无论如何，为了
提高程序的性能，数据结构（尤其是栈）应该尽可能地在自然边界上对齐。原因在于，为
了访问未对齐的内存，处理器需要作两次内存访问；然而，对齐的内存访问仅需要一次访
问。
一个字或双字操作数跨越了4 字节边界，或者一个四字操作数跨越了8 字节边界，被
认为是未对齐的，从而需要两次总线周期来访问内存。一个字起始地址是奇数但却没有跨
越字边界被认为是对齐的，能够在一个总线周期中被访问。某些操作双四字的指令需要内
存操作数在自然边界上对齐。如果操作数没有对齐，这些指令将会产生一个通用保护异常。
双四字的自然边界是能够被16 整除的地址。其他的操作双四字的指令允许未对齐的访问
（不会产生通用保护异常），然而，需要额外的内存总线周期来访问内存中未对齐的数据。
缺省情况下，编译器默认将结构、栈中的成员数据进行内存对齐。因此，上面的程序输
出就变成了：c1 00000000, s 00000002, c2 00000004, i 00000008。编译器将未对齐的成员向后
移，将每一个都成员对齐到自然边界上，从而也导致了整个结构的尺寸变大。尽管会牺牲
一点空间（成员之间有部分内存空闲），但提高了性能。也正是这个原因，我们不可以断言
sizeof(TestStruct1)的结果为8。在这个例子中，sizeof(TestStruct1)的结果为12。
3.6.8.2，如何避免内存对齐的影响
那么，能不能既达到提高性能的目的，又能节约一点空间呢？有一点小技巧可以使用。
比如我们可以将上面的结构改成：
struct TestStruct2
{
char c1;
char c2;
short s;
int i;
};
这样一来，每个成员都对齐在其自然边界上，从而避免了编译器自动对齐。在这个例
子中，sizeof(TestStruct2)的值为8。这个技巧有一个重要的作用，尤其是这个结构作为API
的一部分提供给第三方开发使用的时候。第三方开发者可能将编译器的默认对齐选项改变，
从而造成这个结构在你的发行的DLL 中使用某种对齐方式，而在第三方开发者哪里却使用
另外一种对齐方式。这将会导致重大问题。
比如，TestStruct1 结构，我们的DLL 使用默认对齐选项，对齐为
c1 00000000, s 00000002, c2 00000004, i 00000008，同时sizeof(TestStruct1)的值为12。
而第三方将对齐选项关闭，导致
c1 00000000, s 00000001, c2 00000003, i 00000004，同时sizeof(TestStruct1)的值为8。
除此之外我们还可以利用#pragma pack（）来改变编译器的默认对齐方式（当然一般编译器
也提供了一些改变对齐方式的选项，这里不讨论）。
使用指令#pragma pack (n)，编译器将按照n 个字节对齐。
使用指令#pragma pack ()，编译器将取消自定义字节对齐方式。
在#pragma pack (n)和#pragma pack ()之间的代码按n 个字节对齐。
但是，成员对齐有一个重要的条件,即每个成员按自己的方式对齐.也就是说虽然指定了
按n 字节对齐,但并不是所有的成员都是以n 字节对齐。其对齐的规则是,每个成员按其类型
的对齐参数(通常是这个类型的大小)和指定对齐参数(这里是n 字节)中较小的一个对齐，即：
min( n, sizeof( item )) 。并且结构的长度必须为所用过的所有对齐参数的整数倍,不够就补空
字节。看如下例子：
#pragma pack(8)
struct TestStruct4
{
char a;
long b;
};
struct TestStruct5
{
char c;
TestStruct4 d;
long long e;
};
#pragma pack()
问题：
A),sizeof(TestStruct5) = ?
B), TestStruct5 的c 后面空了几个字节接着是d?
TestStruct4 中,成员a 是1 字节默认按1 字节对齐,指定对齐参数为8,这两个值中取1,a
按1 字节对齐;成员b 是4 个字节,默认是按4 字节对齐,这时就按4 字节对齐,所以
sizeof(TestStruct4)应该为8;
TestStruct5 中,c 和TestStruct4 中的a 一样,按1 字节对齐,而d 是个结构,它是8 个字节,它
按什么对齐呢?对于结构来说,它的默认对齐方式就是它的所有成员使用的对齐参数中最大
的一个, TestStruct4 的就是4.所以,成员d 就是按4 字节对齐.成员e 是8 个字节,它是默认按8
字节对齐,和指定的一样,所以它对到8 字节的边界上,这时,已经使用了12 个字节了,所以又添
加了4 个字节的空,从第16 个字节开始放置成员e.这时,长度为24,已经可以被8(成员e 按8
字节对齐)整除.这样,一共使用了24 个字节.内存布局如下（*表示空闲内存，1 表示使用内存。
单位为1byete）：
a b
TestStruct4 的内存布局：1***,1111,
c TestStruct4.a TestStruct4.b d
TestStruct5 的内存布局： 1***, 1***, 1111, ****，11111111
这里有三点很重要:
首先，每个成员分别按自己的方式对齐,并能最小化长度。
其次，复杂类型(如结构)的默认对齐方式是它最长的成员的对齐方式,这样在成员是复杂
类型时,可以最小化长度。
然后，对齐后的长度必须是成员中最大的对齐参数的整数倍,这样在处理数组时可以保
证每一项都边界对齐。
补充一下,对于数组,比如:char a[3];它的对齐方式和分别写3 个char 是一样的.也就是说
它还是按1 个字节对齐.如果写: typedef char Array3[3];Array3 这种类型的对齐方式还是按1
个字节对齐,而不是按它的长度。
但是不论类型是什么,对齐的边界一定是1,2,4,8,16,32,64....中的一个。
另外，注意别的#pragma pack 的其他用法：
#pragma pack(push) //保存当前对其方式到packing stack
#pragma pack(push,n) 等效于
#pragma pack(push)
#pragma pack(n) //n=1,2,4,8,16 保存当前对齐方式，设置按n 字节对齐
#pragma pack(pop) //packing stack 出栈，并将对其方式设置为出栈的对齐方

>;>; 难道这个 pack 结果与 OS 也相关么？

说对了。默认的内存对齐方式以及内存对齐规则在不同的系统上是有区别的，所以GCC编译器在这一点上在不同的系统上也是区别对待的。

虽然到现在也没有看到GCC在Linux系统下的使用 #pragma pack(N) 的内存对齐规则，但是从我测试的结果来看是这样：默认的对齐是按照 int 型（4字节）对齐，如果指定 #pragma pack(N) 中的 N 的话，N 不能大于默认对齐指定的长度，即如果默认对齐是 4 的话，N的取值可以是 1、2、4，超过 4 之后作为 4 处理。在 Windows 等系统上似乎没有这个限制。

To adacu：

你引用的是在编译时使用 -fpack-struct[=n] 选项的情况。如果没有这个前提，你的说明是不正确的。

另外，现在讨论的是 #pragma pack，是另一种指示内存对齐的方式，你引用的内容不是解释这个情况的，所以说明不了楼主提出的问题

__attribute__((packed))详解

标签：it分类：linux程序

1. __attribute__ ((packed)) 的作用就是告诉编译器取消结构在编译过程中的优化对齐,按照实际占用字节数进行对齐，是GCC特有的语法。这个功能是跟操作系统没关系，跟编译器有关，gcc编译器不是紧凑模式的，我在windows下，用vc的编译器也不是紧凑的，用tc的编译器就是紧凑的。例如：

在TC下：struct my{ char ch; int a;} sizeof(int)=2;sizeof(my)=3;（紧凑模式）

在GCC下：struct my{ char ch; int a;} sizeof(int)=4;sizeof(my)=8;（非紧凑模式）

在GCC下：struct my{ char ch; int a;}__attrubte__ ((packed))sizeof(int)=4;sizeof(my)=5

2. __attribute__关键字主要是用来在函数或数据声明中设置其属性。给函数赋给属性的主要目的在于让编译器进行优化。函数声明中的__attribute__((noreturn))，就是告诉编译器这个函数不会返回给调用者，以便编译器在优化时去掉不必要的函数返回代码。

GNU C的一大特色就是__attribute__机制。__attribute__可以设置函数属性（Function Attribute）、变量属性（Variable Attribute）和类型属性（Type Attribute）。

__attribute__书写特征是：__attribute__前后都有两个下划线，并且后面会紧跟一对括弧，括弧里面是相应的__attribute__参数。

__attribute__语法格式为：

__attribute__ ((attribute-list))

其位置约束：放于声明的尾部“；”之前。

函数属性（Function Attribute）：函数属性可以帮助开发者把一些特性添加到函数声明中，从而可以使编译器在错误检查方面的功能更强大。__attribute__机制也很容易同非GNU应用程序做到兼容之功效。

GNU CC需要使用 –Wall编译器来击活该功能，这是控制警告信息的一个很好的方式。

packed属性：使用该属性可以使得变量或者结构体成员使用最小的对齐方式，即对变量是一字节对齐，对域（field）是位对齐。

如果你看过GPSR协议在TinyOS中的实现，你一定会注意到下面的语句：
typedef struct {
    double x;
    double y;
} __attribute__((packed)) position_t;

开始我们还可以理解，不久是定义一个结构体嘛！不过看到后面的语句，你可能就会一头雾水了，’ __attribute__((packed))’是什么东西？有什么作用？一连串的疑问马上就会从你脑袋里冒出来。虽然这个对理解整个程序没有什么影响，但我不想让这些疑问一直呆在我的脑子里，负担太重。省得以后念念不忘，而且也许有一天可以用的上呢。搞清楚这个问题吧！

GNU C的一大特色（却不被初学者所知）就是__attribute__机制。__attribute__可以设置函数属性（Function Attribute）、变量属性（Variable Attribute）和类型属性（Type Attribute）。
__attribute__语法格式为：
__attribute__ ((attribute-list))

其位置约束为：放于声明的尾部“；”之前。

packed是类型属性（Type Attribute）的一个参数，使用packed可以减小对象占用的空间。需要注意的是，attribute属性的效力与你的连接器也有关，如果你的连接器最大只支持16字节对齐，那么你此时定义32字节对齐也是无济于事的。

使用该属性对struct或者union类型进行定义，设定其类型的每一个变量的内存约束。当用在enum类型定义时，暗示了应该使用最小完整的类型（it indicates that the smallest integral type should be used）。

下面的例子中，my-packed-struct类型的变量数组中的值会紧凑在一起，但内部的成员变量s不会被“pack”，如果希望内部的成员变量也被packed的话，my-unpacked-struct也需要使用packed进行相应的约束。
struct my_unpacked_struct
{
     char c;
     int i;
};
         
struct my_packed_struct
{
     char c;
     int i;
     struct my_unpacked_struct s;
}__attribute__ ((__packed__));

 

 

在每个系统上看下这个结构体的长度吧。
    内存对齐，往往是由编译器来做的，如果你使用的是gcc，可以在定义变量时，添加__attribute__，来决定是否使用内存对齐，或是内存对齐到几个字节，以上面的结构体为例：
 1)到4字节，同样可指定对齐到8字节。
struct student
{
    char name[7];
    uint32_t id;
    char subject[5];
} __attribute__ ((aligned(4))); 

2)不对齐，结构体的长度，就是各个变量长度的和
struct student
{
    char name[7];
    uint32_t id;
    char subject[5];
} __attribute__ ((packed));

 

跨平台时基于数据结构的网络通信

    网络通信通常分为基于数据结构的和基于流的。HTTP协议就是后者的一个例子。
    有时为了提高程序的处理速度和数据处理的方便，会使用基于数据结构的通信（不需要对流进行解析）。但是，当需要在多平台间进行通信时，基于数据结构的通信，往往要十分注意以下几个方面：
[1] 字节序
[2] 变量长度
[3] 内存对齐
    在常见的系统架构中（Linux X86，Windows），非单字节长度的变量类型，都是低字节在前，而在某些特定系统中，如Soalris Sparc平台，高字节在前。如果在发送数据前不进行处理，那么由Linux X86发向Soalris Sparc平台的数据值，势必会有极大的偏差，进而程序运行过程中无法出现预计的正常结果，更严重时，会导致段错误。
    对于此种情况，我们往往使用同一的字节序。在系统中，有ntohXXX(), htonXXX()等函数，负责将数据在网络字节序和本地字节序之间转换。虽然每种系统的本地字节序不同，但是对于所有系统来说，网络字节序是固定的-----高字节在前。所以，可以以网络字节序为通信的标准，发送前，数据都转换为网络字节序。
    转换的过程，也建议使用ntohXXX(), htonXXX()等标准函数，这样代码可以轻松地在各平台间进行移植（像通信这种很少依赖系统API的代码，做成通用版本是不错的选择）。

    变量的长度，在不同的系统之间会有差别，如同是Linux2.6.18的平台，在64位系统中，指针的长度为8个字节，而在32位系统中，指针又是4个字节的长度---此处只是举个例子，很少有人会将指针作为数据发送出去。下面是我整理的在64位Linux系统和32位Linux系统中，几种常见C语言变量的长度：
                short    int    long    long long    ptr    time_t
32位           2         4       4             8               4        4
64位           2         4       8             8               8        8
    在定义通信用的结构体时，应该考虑使用定常的数据类型，如uint32_t，4字节的固定长度，并且这属于标准C库(C99)，在各系统中都可使用。

    内存对齐的问题，也与系统是64位还是32位有关。如果你手头有32位和64位系统，不妨写个简单的程序测试一下，你就会看到同一个结构体，即便使用了定常的数据类型，在不同系统中的大小是不同的。对齐往往是以4字节或8字节为准的，只要你写的测试程序，变量所占空间没有对齐到4或8的倍数即可，举个简单的测试用的结构体的例子吧：
struct student
{
    char name[7];
    uint32_t id;
    char subject[5];
};
    在每个系统上看下这个结构体的长度吧。
    内存对齐，往往是由编译器来做的，如果你使用的是gcc，可以在定义变量时，添加__attribute__，来决定是否使用内存对齐，或是内存对齐到几个字节，以上面的结构体为例：
 1)到4字节，同样可指定对齐到8字节。
struct student
{
    char name[7];
    uint32_t id;
    char subject[5];
} __attribute__ ((aligned(4))); 

2)不对齐，结构体的长度，就是各个变量长度的和
struct student
{
    char name[7];
    uint32_t id;
    char subject[5];
} __attribute__ ((packed));