嵌入式C中使用数组的陷阱

1.使用数组作为形参：
void ClearRAM(char array[])
{
    int i ;
    for(i=0;i<sizeof(array)/sizeof(array[0]);i++)             //这里用法错误，array实际上是指针
       {
              array[i]=0x00;
       }
}
int main(void)
{
       char Fle[20];
       ClearRAM(Fle);                   //只能清除数组Fle中的前四个元素
}
我们知道，对于一个数组array[20]，我们使用代码sizeof(array)/sizeof(array[0])可以获得数组的元素（这里为20），但数组名和指针往往是容易混淆的，而且有且只有一种情况下是可以当做指针的，那就是数组名作为函数形参时，数组名被认为是指针。同时，它不能再兼任数组名。注意只有这种情况下，数组名才可以当做指针，但不幸的是这种情况下容易引发风险。在ClearRAM函数内，作为形参的array[]不再是数组名了，而成了指针。sizeof(array)相当于求指针变量占用的字节数，在32位系统下，该值为4，sizeof(array)/sizeof(array[0])的运算结果也为4。所以在main函数中调用ClearRAM(Fle)，也只能清除数组Fle中的前四个元素了。

2.数组越界

一位同事的代码在硬件上运行，一段时间后就会发现LCD显示屏上的一个数字不正常的被改变。经过一段时间的调试，问题被定位到下面的一段代码中： 

int SensorData[30];

…for(i=30;i>0;i--)

{

SensorData[i]=…;

…

}

这里声明了拥有30个元素的数组，不幸的是for循环代码中误用了本不存在的数组元素SensorData[30]，但C语言却默许这么使用，并欣然的按照代码改变了数组元素SensorData[30]所在位置的值， SensorData[30]所在的位置原本是一个LCD显示变量，这正是显示屏上的那个值不正常被改变的原因。真庆幸这么轻而易举的发现了这个Bug。

其实很多编译器会对上述代码产生一个警告：赋值超出数组界限。但并非所有程序员都对编译器警告保持足够敏感，况且，编译器也并不能检查出数组越界的所有情况。举一个例子，你在模块A中定义数组：

int SensorData[30];

       在模块B中引用该数组，但由于你引用代码并不规范，这里没有显示声明数组大小，但编译器也允许这么做：

extern int SensorData[];

       如果在模块B中存在和上面一样的代码：

       for(i=30;i>0;i--)
       {
              SensorData[i]=…;
              …
       }
       这次，编译器不会给出警告信息，因为编译器压根就不知道数组的元素个数。所以，当一个数组声明为具有外部链接，它的大小应该显式声明。

 再举一个编译器检查不出数组越界的例子。函数func()的形参是一个数组形式，函数代码简化如下所示：

char * func(char SensorData[30])
{
              unsignedint i；
              for(i=30;i>0;i--)
              {
                     SensorData[i]=…;
                     …
              }
}
       这个给SensorData[30]赋初值的语句，编译器也是不给任何警告的。实际上，编译器是将数组名Sensor隐含的转化为指向数组第一个元素的指针，函数体是使用指针的形式来访问数组的，它当然也不会知道数组元素的个数了。造成这种局面的原因之一是C编译器的作者们认为指针代替数组可以提高程序效率，而且，还可以简化编译器的复杂度。

       指针和数组是容易给程序造成混乱的，我们有必要仔细的区分它们的不同。其实换一个角度想想，它们也是容易区分的：可以将数组名等同于指针的情况有且只有一处，就是上面例子提到的数组作为函数形参时。其它时候，数组名是数组名，指针是指针。

下面的例子编译器同样检查不出数组越界。

       我们常常用数组来缓存通讯中的一帧数据。在通讯中断中将接收的数据保存到数组中，直到一帧数据完全接收后再进行处理。即使定义的数组长度足够长，接收数据的过程中也可能发生数组越界，特别是干扰严重时。这是由于外界的干扰破坏了数据帧的某些位，对一帧的数据长度判断错误，接收的数据超出数组范围，多余的数据改写与数组相邻的变量，造成系统崩溃。由于中断事件的异步性，这类数组越界编译器无法检查到。

       如果局部数组越界，可能引发ARM架构硬件异常。同事的一个设备用于接收无线传感器的数据，一次软件升级后，发现接收设备工作一段时间后会死机。调试表明ARM7处理器发生了硬件异常，异常处理代码是一段死循环（死机的直接原因）。接收设备有一个硬件模块用于接收无线传感器的整包数据并存在自己的硬件缓冲区中，当一帧数据接收完成后，使用外部中断通知设备取数据，外部中断服务程序精简后如下所示：

       __irq ExintHandler(void)
       {
              unsignedchar DataBuf[50];
              GetData(DataBug);        //从硬件缓冲区取一帧数据
              …
       }
       由于存在多个无线传感器近乎同时发送数据的可能加之GetData()函数保护力度不够，数组DataBuf在取数据过程中发生越界。由于数组DataBuf为局部变量，被分配在堆栈中，同在此堆栈中的还有中断发生时的运行环境以及中断返回地址。溢出的数据将这些数据破坏掉，中断返回时PC指针可能变成一个不合法值，硬件异常由此产生。

       如果我们精心设计溢出部分的数据，化数据为指令，就可以利用数组越界来修改PC指针的值，使之指向我们希望执行的代码。1988年，第一个网络蠕虫在一天之内感染了2000到6000台计算机，这个蠕虫程序利用的正是一个标准输入库函数的数组越界Bug。起因是一个标准输入输出库函数gets()，原来设计为从数据流中获取一段文本，遗憾的是，gets()函数没有规定输入文本的长度。gets()函数内部定义了一个500字节的数组，攻击者发送了大于500字节的数据，利用溢出的数据修改了堆栈中的PC指针，从而获取了系统权限。