判断大小端

下面这段代码可以用来测试一下你的编译器是大端模式还是小端模式：short int x;

char x0,x1;

x=0x1122;

x0=((char*)&x)[0]; //低地址单元

x1=((char*)&x)[1]; //高地址单元

若x0=0x11,则是大端; 若x0=0x22,则是小端......

上面的程序还可以看出，数据寻址时，用的是低位字节的地址。

Endianess是个比较tricky的问题，特别是当数据在不同类型间转换时。

先看看在一台32位的little-endian机器上，以下代码的行为：

C代码  

1. #include <stdio.h> // memcpy  
2. #include <stdlib.h> // printf  
3.   
4. typedef struct {  
5.     char a;  
6.     char b;  
7.     char c;  
8.     char d;  
9. } st;  
10.   
11. void main() {  
12.     st s;      
13.     memcpy(&s, "RednaxelaFX", sizeof(s));  
14.     printf("sizeof(s) = %d\n", sizeof(s)); // 4  
15.     printf("%X\n", s); // 6E646552  
16.     printf("%c, %c, %c, %c\n", s.a, s.b, s.c, s.d); // R, e, d, n  
17. }  

在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上的执行结果就会变成：

C代码  

1. #include <stdio.h>  
2. #include <stdlib.h>  
3.   
4. typedef struct {  
5.     short a;  
6.     short b;  
7. } st;  
8.   
9. void main() {  
10.     st s;      
11.     memcpy(&s, "RednaxelaFX", sizeof(s));  
12.     printf("sizeof(s) = %d\n", sizeof(s)); // 4  
13.     printf("%X\n", s); // 6E646552  
14.     printf("%X, %X\n", s.a, s.b); // 6552, 6E64  
15. }  

也就是把'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为例，这两个编译器在这个例子中行为一样。观察下面代码

C代码  

1. #include <stdio.h>  
2. #include <stdlib.h>  
3.   
4. typedef struct {  
5.     int a:5;  
6.     int :2;  
7.     int b:2;  
8. } bitstruct;  
9.   
10. void main() {  
11.     bitstruct b;  
12.     memcpy(&b, "RednaxelaFX", sizeof(b));  
13.     printf("sizeof(b) = %d\n", sizeof(b)); // 4  
14.     printf("%X\n", b); // 6E646552  
15.     printf("%X, %X\n", b.a, b.b); // FFFFFFF2, FFFFFFFE  
16.     printf("%d, %d\n", b.a, b.b); // -14, -2  
17. }  

例子中的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

如果还是觉得没转过脑筋来，那么这样看：实际由编译器编译出来会像这样：（只是用于表现概念）

C代码  

1. bitstruct b;  
2. int temp;  
3. // assign to b, make some changes, whatever...  
4.   
5. // here's what's supposed to be "temp = b.a":  
6. temp = (int)b;  
7. temp <<= 27; // 27 == 32 - 5  
8. temp >>= 27; // 27 == 32 - 5  
9.   
10. // and here's what's supposed to be "temp = b.b":  
11. temp = (int)b;  
12. temp <<= 23; // 23 == 32 - 5 - 2 - 2  
13. 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存储的顺序。