struct bit-field与little-endian

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存储的顺序。

评论

2 楼 utensil 2009-05-26  

好文，阐述得非常透彻。

1 楼 lwwin 2008-10-25  

没错，
然特别是媒体库皆由宏定义……
故从未能顺利编译此类LIB