struct bit-field与little-endian - Script Ahead, Code Behind - ITeye技术网站
Endianess是个比较tricky的问题，特别是当数据在不同类型间转换时。
先看看在一台32位的little-endian机器上，以下代码的行为：
- #include <stdio.h> // memcpy
- #include <stdlib.h> // printf
- typedef struct {
- char a;
- char b;
- char c;
- char d;
- } st;
- void main() {
- st s;
- memcpy(&s, "RednaxelaFX", sizeof(s));
- printf("sizeof(s) = %d\n", sizeof(s)); // 4
- printf("%X\n", s); // 6E646552
- printf("%c, %c, %c, %c\n", s.a, s.b, s.c, s.d); // R, e, d, n
- }
在32位x86上有4字节的对齐，正好4个char就是4字节于是st中没有padding。可以看到，struct中的成员是按声明顺序从低地址到高地址排列的。C99规范的6.7.2.1规定了这点。一个数组是一块连续的、有序的空间，而一个字符串是一个char数组，所以可以看到s.a, s.b, s.c, s.d跟字符串（char数组）的开头4个字符（字节）对应：'R' 'e' 'd' 'n'（52 65 64 6E）分成4段：（| 52 | 65 | 64 | 6E |）分别对应s.a到s.d。
但将该struct解释为一个32位的整型，并以十六进制的方式显示出来，则会发现字节的顺序颠倒了过来：
原本'R' 'e' 'd' 'n'的十六进制表示是52 65 64 6E；转换为一个整型之后，则变为0x6E646552，字节的顺序正好反了过来。注意是字节而不是位的顺序反了过来，字节内的位的顺序依然保持不变。
这体现了little-endian机器上对数据解释方式的不同。在内存中的数据在参与运算前会先加载到寄存器中，字节序（endian）的差异就在这一步上：如果是big-endian，则读到寄存器的数据的字节序跟内存中的一样；反之如果是little-endian，则读到寄存器的数据的字节序跟内存中的相反。
说“相反”，到底在多大的范围内“相反”呢？这就要看运算涉及的数据类型（特指原始数据类型dword/word/byte等）的宽度了：数据类型有多宽，就在多少字节间需要将字节顺序反转过来。如果上面的st中不是含有4个char而是含有两个short，那么在32位x86上的执行结果就会变成：
- #include <stdio.h>
- #include <stdlib.h>
- typedef struct {
- short a;
- short b;
- } st;
- void main() {
- st s;
- memcpy(&s, "RednaxelaFX", sizeof(s));
- printf("sizeof(s) = %d\n", sizeof(s)); // 4
- printf("%X\n", s); // 6E646552
- printf("%X, %X\n", s.a, s.b); // 6552, 6E64
- }
也就是把'R' 'e' 'd' 'n'（52 65 64 6E）分成两段（| 52 65 | 64 6E |），然后将字节的顺序反转过来解释为整型数字（0x6552，0x6E64）。直接解释为一个32位整型的时候，'R' 'e' 'd' 'n'（52 65 64 6E）分成一段（| 52 65 64 6E |），并在这一段内反转字节顺序得到0x6E646552。
前面用4个char为例时，因为每个单元的数据本身就只有1字节，反转不反转没有差别，所以无论是在big-endian还是在little-endian机器上执行的结果都会是一样的。
再次强调：字节序只影响解释数据时字节间的顺序，不影响每个字节内的位的顺序。
===========================================================================
那么结合C struct里的bitfield又会怎样的？
还是在C99规范的6.7.2.1节里，规范规定了可以对struct中的field显式指定宽度（以bit为单位）；显式指定了宽度的field被称为bit-field。规范中同一小节中的第10点有如下说明：引用An implementation may allocate any addressable storage unit large enough to hold a bitfield. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.
根据该说明，规范留下了许多故意未定义的地方，包括红字标出的：同一单元内排列bit-field的顺序未定义。所以我们无法根据规范确定同一组bit-field到底哪个在前哪个在后。
虽然如此，具体到某个机器上某个编译器所编译出来的结果还是需要解释的。这里以32位x86搭配VC9/GCC3.4为例，这两个编译器在这个例子中行为一样。观察下面代码
- #include <stdio.h>
- #include <stdlib.h>
- typedef struct {
- int a:5;
- int :2;
- int b:2;
- } bitstruct;
- void main() {
- bitstruct b;
- memcpy(&b, "RednaxelaFX", sizeof(b));
- printf("sizeof(b) = %d\n", sizeof(b)); // 4
- printf("%X\n", b); // 6E646552
- printf("%X, %X\n", b.a, b.b); // FFFFFFF2, FFFFFFFE
- printf("%d, %d\n", b.a, b.b); // -14, -2
- }
例子中的bitstruct中有3个bit-field，第一个是名字为a的5位带符号整型，第二个是匿名的2位带符号整形，第三个是名字为b的2位带符号整型，加起来一共是9位，但32位x86上有4字节对齐的要求，所以经过padding后，bitstruct的宽度是4字节（32位）。从存储单元的角度看，1个dword（32位）就是1个存储单元，bitstruct中包含一个存储单元，并且其中的3个成员都在这个存储单元中。bitstruct.a占有“前”5位，匿名field占有紧接着的2位，然后bitstruct.b占有接下来的2位（注意“前”到底是从哪边开始在规范中并没有定义）。
这个宽度与前面两个例子中的st一样，当然执行到printf("%X\n", b);这句的时候结果也一样。关键就在这其中的bit-field是如何解释成-14和-2的。
从结果来看，可以知道：bitstruct的3个field都在同一个存储单元内，并且由于x86是little-endian的，数据从内存读到寄存器之后字节序就反了过来，高位字节到低位字节的顺序是“从右向左”；对应的，解释bitstruct中的各field时也从右向左来读。
寄存器中的b：
'n' 'd' 'e' 'R'
6E 64 65 52
用二进制表示就是：
01101110 01100100 01100101 01010010
“从右向左”来数宽度，最靠右的5位是b.a，其左边2位是匿名field，然后再左边2位是b.b。注意：从右向左数的是宽度，不是数据内容的位的顺序。
那么就有（二进制）：
b.a: 10010
b.b: 10
由于这两个field是带符号的整型，读出来的时候需要做带符号扩展到一个int，于是它们就分别扩展到（十六进制）：
b.a: FFFFFFF2
b.b: FFFFFFFE
换回用普通的带符号十进制表示也就是：
b.a: -14
b.b: -2
如果还是觉得没转过脑筋来，那么这样看：实际由编译器编译出来会像这样：（只是用于表现概念）
- bitstruct b;
- int temp;
- // assign to b, make some changes, whatever...
- // here's what's supposed to be "temp = b.a":
- temp = (int)b;
- temp <<= 27; // 27 == 32 - 5
- temp >>= 27; // 27 == 32 - 5
- // and here's what's supposed to be "temp = b.b":
- temp = (int)b;
- temp <<= 23; // 23 == 32 - 5 - 2 - 2
- temp >>= 30; // 30 == 32 - 2
注意：
1. temp = (int)b;这里，把bitstruct里的数据解释为单个32位整型时，little-endian的作用就体现出来了；在4个字节的范围内字节的顺序需要反转过来。
2. 左移27位再右移27位与直接拿0x01F来做mask是不等价的：前者的右移是带符号的，而后者直接把符号掩盖掉了。
--------------------------------------------------------------------------
需要在说明一次，规范中并没有规定一定要按照这个顺序，只是这个例子选用的机器+编译器组合中有这样的行为而已。bit-field在存储单元内安排的顺序如何从一般程序中是看不出来的，因为：引用The unary & (address-of) operator cannot be applied to a bit-field object; thus, there are no pointers to or arrays of bit-field objects.
无法获得单一bit-field的地址（但可以获得这个bit-field所在的存储单元的起始地址），所以一般程序无从得知到底bit-field是从哪边开始存的；编译器会生成合适的位移指令序列来得到bit-field的值/对bit-field赋值。程序不应该依赖于bit-field存储的顺序。