这也是在ChinaUnix上看了几篇关于C语言'位域(Bit Fields)'的帖子之后，才想写下这篇文章的。其实在平时的工作中很少使用到'位域'，我是搞服务器端程序设计的，大容量的内存可以让我毫不犹豫的任意'挥霍'^_^。想必搞嵌入式编程的朋友们对位域的使用应该不陌生吧。这里我也仅仅是凭着对C语言钻研的兴趣来学习一下'位域'的相关知识的，可能有些说法没有实践，缺乏说服力。

具体也不是很清楚当年C语言的创造者为什么要加入位域这一语法支持，那是太遥远的事情了，我们不需要再回顾了，既然大师们为我们创造了它，我们使用便是了。

毋庸置疑，位域的引入给用户的最大的好处莫过于可以有效的利用'昂贵'的内存和操作bit的能力了。而且这种操作bit位的能力很是方便，利用结构体域名即可对这些bit进行操作。例如：

struct foo {
 int a : 1;
 int b : 2;
 short c : 1;
};

struct foo aFoo;
aFoo.a = 1;
aFoo.b = 3;
aFoo.c = 0;

通过结构体实例.域名即可修改某些bit得值，这些都是编译器的'甜头'。当然我们也可以自己通过一些'掩码'和移位操作来修改这些bit，当然如果不是十分需要，我们是不需要这么做的。

位域还提供一种叫'匿名'位域的语法，它常用来'填缺补漏'，由于是'匿名'，所以你不能像上面那样去访问它。如：
struct foo1 {
 int a : 1;
 int   : 2;
 short c : 1;
};
在foo1的成员a和c之间有一个2 bits的匿名位域。

在foo结构体的定义中，成员a虽然类型为int，但是它仅仅占据着4个字节中的一个bit的空间；类似b占据2个bit空间，但是b到底是占据第一个int的2个bit空间呢还是第二个int的2个bit空间呢？这里实际上也涉及到如何对齐带有'位域'的结构体这样一个问题。我们来分析一下。

我们再来看看下面两个结构体定义：
struct foo2 {
        char    a : 2;
        char    b : 3;
        char    c : 1;
};

struct foo3 {
        char    a : 2;
        char    b : 3;
        char    c : 7;
};
我们来打印一下这两个结构体的大小，我们得到的结果是：
sizeof(struct foo2) = 1
sizeof(struct foo3) = 2
显然都不是我们期望的，如果按照正常的内存对齐规则，这两个结构体大小均应该为3才对，那么问题出在哪了呢？首先通过这种现象我们可以肯定的是：带有'位域'的结构体并不是按照每个域对齐的，而是将一些位域成员'捆绑'在一起做对齐的。以foo2为例，这个结构体中所有的成员都是char型的，而且三个位域占用的总空间为6 bit 8 bit(1 byte)，这里位域是不能跨越两个成员基本类型空间的，这时编译器将a和b两个成员'捆绑'按照char做对齐，而c单独拿出来以char类型做对齐，这样实际上在b和c之间出现了空隙，但这也是最节省空间的方法了。我们再看一种结构体定义：

struct foo4 {
        char    a : 2;
        char    b : 3;
        int c : 1;
};

在foo4中虽然三个位域所占用空间之和为6 bit < 8 bit(1 byte)，但是由于char和int的对齐系数是不同的，是不能捆绑在一起，那是不是a、b捆绑在一起按照char对齐，c单独按照int对齐呢？我们打印一下sizeof(struct foo4)发现结果为4，也就是说编译器把a、b、c一起捆绑起来并以int做对齐了。

通过上面的例子我们发现很难总结出很规律性的东西，但是带有'位域'的结构体的对齐有条原则可以遵循，那就是："尽量减少结构体的占用空间"。当然显式的使用内存对齐的机会也并不多。^_^

下午到ChinaUnix C/C++版看了看，发现一个比较有意思的问题，一位兄弟在其帖子中问一段很简单的程序明显有数组越界访问之错误，可程序为什么运行起来却’安然无恙’，我看看了看，也给出了我自己的回复，晚上下班后又想想了这个问题，决定写一篇blog说说。

这位仁兄的程序(据他个人说来源自’GNU/Linux编程指南’)是这样的：

#define BIGNUM 50

void index_to_the_moon(int arr[]);

int main(void)
{
        int intary[10];
        index_to_the_moon(intary);

        exit(EXIT_SUCCESS);
}

void index_to_the_moon(int arr[])
{
        int i;
        for(i=0;i<bignum;i++)
        {
                arr[i]=i;
                printf("%d\n",arr[i]);
        }
}

正如这位楼主所说，这段代码很简单，相信学过2天C程序的人都能看得懂。按照楼主所说我在公司的环境(Solaris 9, Gcc 3.4)编译运行了这段代码，果然让楼主言中了，程序’安然无恙’的运行结束，没有任何异常。在那个帖子的回复中很多人说原因：’C不对数组下标越界进行检查，如果越界访问，其结果未定义’。这些回答其实也没有错，我在Windows XP, mingw Gcc 3.4.2下也试过编译运行该程序，结果是当打印输出到47，程序就中止了，也没有任何提示或者错误出现，估计是Windows OS中途将之Kill掉了。我们还是不说Windows上的东西比较好，我们还是主要以Unix平台为例，为什么Unix平台运行该程序一切OK呢？我们不妨分析一下：

明眼人都看得出来，该程序的确是越界访问数组了，但这只是表面想象或者说是违反了C语言的约束的做法，而更进一步说越界访问的结果是什么呢？Unix OS凭什么知道需要给出错误信息(Dump Core)呢？直截了当地说这个程序里面只是’污染’了用户进程地址空间中的一个叫’栈’的空间，我们回顾一下一个应用程序它的进程地址空间是一个什么样的布局(这个在’C专家编程’一书中有说明)：

———— 0xFFFFFFFF(高地址)
栈  (stack bottom)

    (stack top)
————
  |
  |
 \|/
 空洞
 /|\
  |
————
堆

————
数据段
————
文本段
———— 0×00000000(低地址)

按照上面的布局，我们来大致确定一下那个程序中各个变量的位置，当然我们主要聚焦在栈区了，我们要看看index_to_the_moon函数到底污染了栈上的哪些区域？在main函数中程序定义了一个局部数组变量intary，之后调用了函数index_to_the_moon，我们可以得到一个这样的栈布局：
—————————
stack bottom(high addess)
    |
   \|/
————–
main的返回地址
————–
saved %ebp
————–
intary[9]
————–
…
————–
intary[0]
…
————–
index_to_the_moon返回地址
….

    |
   \|/
stack top(low address)
————————–

从这个布局中我们可以看得出来，在栈上，intary中的各个元素的排列，通过打印出intary[0]和intary[1]的地址我们即可推导出其伸展方向，这样已经一目了然了，从intary[0]到intary[9]是从低地址到高地址分配的，这样我们可以推断如果有intary[10]，其地址应该在intary[9]的高地址方向上，这样在index_to_the_moon中越界修改的栈数据就是沿着高地址方向的污染，而高地址方向存储的是什么呢，继续看图，沿着高地址方向依次是main的返回地址、以及调用main函数的_start函数的访问地址以及他们的参数列表和相关局部变量，当然_start函数究竟是什么样子的我们不得而知。但是污染了这些数据会不会导致core的出现呢？我觉得可能性不大，我想当main函数调用exit或者return后用户进程退出了，OS只是象征性的到栈上取一些返回值罢了，至于这些值是0还是796，意义已经不大。

那是不是这样越界下去就永远不会出问题了呢？当然不是。你把上面程序中的BIGNUM换成1000看看，起码在我的环境上，当printf访问到intary[654]的时候，出现了’段错误 ((主存储器)信息转储)’，这又是为什么呢？我们都知道我们现在的OS采用的都是虚拟存储管理，我们的进程地址空间也是虚拟地址，当我们无限制的沿着高低址方向试图访问数据时，所访问的虚拟地址值就会最终’进入内核空间’或者’溢出当前内存页所能表示的虚拟内存地址’而导致访问违例，当你访问违法的地址时出错就是必然的了。