嵌入式軟件可靠性設(shè)計(jì)要注意的問題

設(shè)備的可靠性涉及多個(gè)方面：穩(wěn)定的硬件、優(yōu)秀的軟件架構(gòu)、嚴(yán)格的測(cè)試以及市場(chǎng)和時(shí)間的檢驗(yàn)等等。這里著重談一下對(duì)嵌入式軟件可靠性設(shè)計(jì)的一些理解，通過一定的技巧和方法提高軟件可靠性。這里所說的嵌入式設(shè)備,是指使用單片機(jī)、ARM7、Cortex-M0，M3之類為核心的測(cè)控或工控系統(tǒng)。

?

嵌入式軟件可靠性設(shè)計(jì)應(yīng)該從防錯(cuò)、判錯(cuò)和容錯(cuò)三方面進(jìn)行考慮. 此外,還需理解自己所使用的編譯器特性。??

此文屬拋磚引玉. ? ??

良好的軟件架構(gòu)、清晰的代碼結(jié)構(gòu)、掌握硬件、深入理解C語言是防錯(cuò)的要點(diǎn)，這里只談一下C語言。

“人的思維和經(jīng)驗(yàn)積累對(duì)軟件可靠性有很大影響"。C語言詭異且有種種陷阱和缺陷，需要程序員多年歷練才能達(dá)到較為完善的地步。“軟件的質(zhì)量是由程序員的質(zhì)量以及他們相互之間的協(xié)作決定的”。因此，作者認(rèn)為防錯(cuò)的重點(diǎn)是要考慮人的因素。

“深入一門語言編程，不要浮于表面”。軟件的可靠性，與你理解的語言深度密切相關(guān)，嵌入式C更是如此。除了語言，作者認(rèn)為嵌入式開發(fā)還必須深入理解編譯器。

本節(jié)將對(duì)C語言的陷阱和缺陷做初步探討。

最初開始編程時(shí)，除了英文標(biāo)點(diǎn)被誤寫成中文標(biāo)點(diǎn)外，可能被大家普遍遇到的是將比較運(yùn)算符==誤寫成賦值運(yùn)算符=，代碼如下所示：

? ? ? ? ? ?

? ?if(x=5) { … }

這里本意是比較變量x是否等于常量5，但是誤將’==’寫成了’=’，if語句恒為真。如果在邏輯判斷表達(dá)式中出現(xiàn)賦值運(yùn)算符，現(xiàn)在的大多數(shù)編譯器會(huì)給出警告信息。并非所有程序員都會(huì)注意到這類警告，因此有經(jīng)驗(yàn)的程序員使用下面的代碼來避免此類錯(cuò)誤：

? ? ? ??

? ? ? if(5==x) { … }

將常量放在變量x的左邊，即使程序員誤將’==’寫成了’=’，編譯器會(huì)產(chǎn)生一個(gè)任誰也不能無視的語法錯(cuò)誤信息：不可給常量賦值！

?

+=與=+、-=與=-也是容易寫混的。復(fù)合賦值運(yùn)算符（+=、*=等等）雖然可以使表達(dá)式更加簡(jiǎn)潔并有可能產(chǎn)生更高效的機(jī)器代碼，但某些復(fù)合賦值運(yùn)算符也會(huì)給程序帶來隱含Bug，如下所示代碼：

? ? ? ? ??

? ? tmp=+1;

該代碼本意是想表達(dá)tmp=tmp+1，但是將復(fù)合賦值運(yùn)算符+=誤寫成=+：將正整數(shù)常量1賦值給變量tmp。編譯器會(huì)欣然接受這類代碼，連警告都不會(huì)產(chǎn)生。

如果你能在調(diào)試階段就發(fā)現(xiàn)這個(gè)Bug，你真應(yīng)該慶祝一下，否則這很可能會(huì)成為一個(gè)重大隱含Bug，且不易被察覺。

?

-=與=-也是同樣道理。與之類似的還有邏輯與&&和位與&、邏輯或||和位或|、邏輯非！和位取反~。此外字母l和數(shù)字1、字母O和數(shù)字0也易混淆，這種情況可借助編譯器來糾正。

? ? ???

很多的軟件BUG自于輸入錯(cuò)誤。在Google上搜索的時(shí)候，有些結(jié)果列表項(xiàng)中帶有一條警告，表明Google認(rèn)為它帶有惡意代碼。如果你在2009年1月31日一大早使用Google搜索的話，你就會(huì)看到，在那天早晨55分鐘的時(shí)間內(nèi)，Google的搜索結(jié)果標(biāo)明每個(gè)站點(diǎn)對(duì)你的PC都是有害的。這涉及到整個(gè)Internet上的所有站點(diǎn)，包括Google自己的所有站點(diǎn)和服務(wù)。Google的惡意軟件檢測(cè)功能通過在一個(gè)已知攻擊者的列表上查找站點(diǎn)，從而識(shí)別出危險(xiǎn)站點(diǎn)。在1月31日早晨，對(duì)這個(gè)列表的更新意外地包含了一條斜杠(“/”)。所有的URL都包含一條斜杠，并且，反惡意軟件功能把這條斜杠理解為所有的URL都是可疑的，因此，它愉快地對(duì)搜索結(jié)果中的每個(gè)站點(diǎn)都添加一條警告。很少見到如此簡(jiǎn)單的一個(gè)輸入錯(cuò)誤帶來的結(jié)果如此奇怪且影響如此廣泛，但程序就是這樣，容不得一絲疏忽。

?

數(shù)組常常也是引起程序不穩(wěn)定的重要因素，C語言數(shù)組的迷惑性與數(shù)組下標(biāo)從0開始密不可分，你可以定義int a[30]，但是你絕不可以使用數(shù)組元素a[30]，除非你自己明確知道在做什么。

?

switch…case語句可以很方便的實(shí)現(xiàn)多分支結(jié)構(gòu)，但要注意在合適的位置添加break關(guān)鍵字。程序員往往容易漏加break從而引起順序執(zhí)行多個(gè)case語句，這也許是C的一個(gè)缺陷之處。對(duì)于switch…case語句，從概率論上說，絕大多數(shù)程序一次只需執(zhí)行一個(gè)匹配的case語句，而每一個(gè)這樣的case語句后都必須跟一個(gè)break。去復(fù)雜化大概率事件，這多少有些不合常情。

?

break關(guān)鍵字用于跳出最近的那層循環(huán)語句或者switch語句，但程序員往往不夠重視這一點(diǎn)。

1990年1月15日，AT&T電話網(wǎng)絡(luò)位于紐約的一臺(tái)交換機(jī)當(dāng)機(jī)并且重啟，引起它鄰近交換機(jī)癱瘓，由此及彼，一個(gè)連著一個(gè)，很快，114臺(tái)交換機(jī)每六秒當(dāng)機(jī)重啟一次，六萬人九小時(shí)內(nèi)不能打長途電話。當(dāng)時(shí)的解決方式：工程師重裝了以前的軟件版本。事后的事故調(diào)查發(fā)現(xiàn)，這是break關(guān)鍵字誤用造成的?！禖專家編程》提供了一個(gè)簡(jiǎn)化版的問題源碼：

network code()
{
 ? ? ? switch(line) {
 ? ? ? ? ? ? ?case ?THING1:
 ? ? ? ? ? ? ? ? ? ? doit1();
 ? ? ? ? ? ? ?break;
 ? ? ? ? ? ? ?case ?THING2:
 ? ? ? ? ? ? ? ? ? ? if(x==STUFF) {
 ? ? ? ? ? ? ? ? ? ? ? ? ? ?do_first_stuff();
 ? ? ? ? ? ? ? ? ? ? ? ? ? ?if(y==OTHER_STUFF)
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
 ? ? ? ? ? ? ? ? ? ? ? ? ? ?do_later_stuff();
 ? ? ? ? ? ? ? ? ? ? } /*代碼的意圖是跳轉(zhuǎn)到這里… …*/
 ? ? ? ? ? ? ? ? ? ? initialize_modes_pointer();
 ? ? ? ? ? ? ?break;
 ? ? ? ? ? ? ?default:
 ? ? ? ? ? ? ? ? ? ? processing();
 ? ? ? }/*… …但事實(shí)上跳到了這里。*/
 ? ? ? use_modes_pointer();/*致使modes_pointer未初始化*/
}

那個(gè)程序員希望從if語句跳出，但他卻忘記了break關(guān)鍵字實(shí)際上跳出最近的那層循環(huán)語句或者switch語句?，F(xiàn)在它跳出了switch語句，執(zhí)行了use_modes_pointer()函數(shù)。但必要的初始化工作并未完成，為將來程序的失敗埋下了伏筆。

?

將一個(gè)整形常量賦值給變量，代碼如下所示：

?????? ?

??????int?a=34, b=034;

變量a和b相等嗎？答案是不相等的。我們知道，16進(jìn)制常量以’0x’為前綴，10進(jìn)制常量不需要前綴，那么8進(jìn)制呢？它與10進(jìn)制和16進(jìn)制表示方法都不相通，它以數(shù)字’0’為前綴，這多少有點(diǎn)奇葩：三種進(jìn)制的表示方法完全不相通。如果8進(jìn)制也像16進(jìn)制那樣以數(shù)字和字母表示前綴的話，或許更有利于減少軟件Bug，畢竟你使用8進(jìn)制的次數(shù)可能都不會(huì)有誤使用的次數(shù)多！下面展示一個(gè)誤用8進(jìn)制的例子，最后一個(gè)數(shù)組元素賦值錯(cuò)誤：

a[0]=106; ? ? ? ? ? ? ?/*十進(jìn)制數(shù)106*/
a[1]=112; ? ? ?/*十進(jìn)制數(shù)112*/
a[2]=052; ? ? ? ? ? ? ?/*實(shí)際為十進(jìn)制數(shù)42，本意為十進(jìn)制52*/

指針的加減運(yùn)算是特殊的。下面的代碼運(yùn)行在32位ARM架構(gòu)上，執(zhí)行之后，a和p的值分別是多少？

 ? ? ? ? ? ? ?int a=1;
 ? ? ? ? ? ? ?int *p=(int*)0x00001000;
 ? ? ? ? ? ? ?a=a+1;
 ? ? ? ? ? ? ?p=p+1;

對(duì)于a的值很容判斷出結(jié)果為2，但是p的結(jié)果卻是0x00001004。指針p加1后，p的值增加了4，這是為什么呢？原因是指針做加減運(yùn)算時(shí)是以指針的數(shù)據(jù)類型為單位。p+1實(shí)際上是p+1*sizeof(int)。不理解這一點(diǎn)，在使用指針直接操作數(shù)據(jù)時(shí)極易犯錯(cuò)。比如下面對(duì)連續(xù)RAM初始化零操作代碼:

unsigned int *pRAMaddr; ? ? ? ? ? ? ? ? ? //定義地址指針變量
for(pRAMaddr=StartAddr;pRAMaddr{
 ? ? ? ? ? *pRAMaddr=0x00000000; ? ?//指定RAM地址清零
}

由于pRAMaddr是一個(gè)指針變量,所以pRAMaddr+=4代碼其實(shí)使pRAMaddr偏移了4*sizeof(int)=16個(gè)字節(jié)，所以每執(zhí)行一次for循環(huán)，會(huì)使變量pRAMaddr偏移16個(gè)字節(jié)空間，但只有4字節(jié)空間被初始化為零。其它的12字節(jié)數(shù)據(jù)的內(nèi)容，在大多數(shù)架構(gòu)處理器中都會(huì)是隨機(jī)數(shù)。

?

對(duì)于sizeof()，這里強(qiáng)調(diào)兩點(diǎn)，第一它是一個(gè)關(guān)鍵字，而不是函數(shù)，并且它默認(rèn)返回?zé)o符號(hào)整形數(shù)據(jù)（要記住是無符號(hào)）；第二，使用sizeof獲取數(shù)組長度時(shí)，不要對(duì)指針應(yīng)用sizeof操作符，比如下面的例子：

void ClearRAM(char array[])
{
 ? ?int i ;
 ? ?for(i=0;i ? ? ? {
 ? ? ? ? ? ? ?array[i]=0x00;
 ? ? ? }
}
 
int main(void)
{
 ? ? ? char Fle[20];
 ? ? ?
 ? ? ? ClearRAM(Fle); ? ? ? ? ? ? ? ? ? //只能清除數(shù)組Fle中的前四個(gè)元素
}

我們知道，對(duì)于一個(gè)數(shù)組array[20]，我們使用代碼sizeof(array)/sizeof(array[0])可以獲得數(shù)組的元素（這里為20），但數(shù)組名和指針往往是容易混淆的，而且有且只有一種情況下是可以當(dāng)做指針的，那就是數(shù)組名作為函數(shù)形參時(shí)，數(shù)組名被認(rèn)為是指針。同時(shí)，它不能再兼任數(shù)組名。注意只有這種情況下，數(shù)組名才可以當(dāng)做指針，但不幸的是這種情況下容易引發(fā)風(fēng)險(xiǎn)。在ClearRAM函數(shù)內(nèi)，作為形參的array[]不再是數(shù)組名了，而成了指針。sizeof(array)相當(dāng)于求指針變量占用的字節(jié)數(shù)，在32位系統(tǒng)下，該值為4，sizeof(array)/sizeof(array[0])的運(yùn)算結(jié)果也為4。所以在main函數(shù)中調(diào)用ClearRAM(Fle)，也只能清除數(shù)組Fle中的前四個(gè)元素了。

?

增量運(yùn)算符++和減量運(yùn)算符--既可以做前綴也可以做后綴。前綴和后綴的區(qū)別在于值的增加或減少這一動(dòng)作發(fā)生的時(shí)間是不同的。作為前綴是先自加或自減然后做別的運(yùn)算，作為后綴時(shí)，是先做運(yùn)算，之后再自加或自減。許多程序員對(duì)此認(rèn)識(shí)不夠，就容易埋下隱患。下面的例子可以很好的解釋前綴和后綴的區(qū)別。

int a=8,b=2,y;
y=a+++--b;

代碼執(zhí)行后，y的值是多少？

這個(gè)例子并非是挖空心思設(shè)計(jì)出來專門讓你絞盡腦汁的C難題（如果你覺得自己對(duì)C細(xì)節(jié)掌握很有信心，做一些C難題檢驗(yàn)一下是個(gè)不錯(cuò)的選擇。那么，《The C Puzzle Book》這本書一定不要錯(cuò)過。），你甚至可以將這個(gè)難懂的語句作為不友好代碼的反面例子。但是它也可以讓你更好的理解C語言。根據(jù)運(yùn)算符優(yōu)先級(jí)以及編譯器識(shí)別字符的貪心法原則，代碼y=a+++--b;可以寫成更明確的形式：

y=(a++)+(--b);

當(dāng)賦值給變量y時(shí)，a的值為8，b的值為1,所以變量y的值為9；賦值完成后，變量a自加，a的值變?yōu)?，千萬不要以為y的值為10。這條賦值語句相當(dāng)于下面的兩條語句：

y=a+(--b);
a=a+1;

為了更簡(jiǎn)單的設(shè)計(jì)編譯器，目前幾乎所有編譯器的語義檢查都比較弱小，加之為了獲得更快的執(zhí)行效率，C語言被設(shè)計(jì)的足夠靈活且?guī)缀醪贿M(jìn)行任何運(yùn)行時(shí)檢查，比如數(shù)組越界、指針是否合法、運(yùn)算結(jié)果是否溢出等等。

C語言足夠靈活，對(duì)于一個(gè)數(shù)組a[30]，它允許使用像a[-1]這樣的形式來快速獲取數(shù)組首元素所在地址前面的數(shù)據(jù)；允許將一個(gè)常數(shù)強(qiáng)制轉(zhuǎn)換為函數(shù)指針，使用代碼(*((void(*)())0))()來調(diào)用位于0地址的函數(shù)。C語言給了程序員足夠的自由，但也由程序員承擔(dān)濫用自由帶來的責(zé)任。下面的兩個(gè)例子都是死循環(huán)，如果在不常用分支中出現(xiàn)類似代碼，將會(huì)造成看似莫名其妙的死機(jī)或者重啟。

a.?????unsigned char?i；??????????????????? b. ??unsigned chari;

???????for(i=0;i<256;i++)? {… }?????????????????for(i=10;i>=0;i--) { … }

對(duì)于無符號(hào)char類型，表示的范圍為0~255，所以無符號(hào)char類型變量i永遠(yuǎn)小于256（第一個(gè)for循環(huán)無限執(zhí)行），永遠(yuǎn)大于等于0（第二個(gè)for循環(huán)無線執(zhí)行）。需要說明的是，賦值代碼i=256是被C語言允許的，即使這個(gè)初值已經(jīng)超出了變量i可以表示的范圍。C語言會(huì)千方百計(jì)的為程序員創(chuàng)造出錯(cuò)的機(jī)會(huì)，可見一斑。

??????

假如你在if語句后誤加了一個(gè)分號(hào)改變了程序邏輯，編譯器也會(huì)很配合的幫忙掩蓋，甚至連警告都不提示。代碼如下：

 ? ? ? if(a>b); ? ? ? ? ?//這里誤加了一個(gè)分號(hào)
 ? ? ? a=b; ? ? ? ? ? ? ? //這句代碼一直被執(zhí)行

不但如此，編譯器還會(huì)忽略掉多余的空格符和換行符，就像下面的代碼也不會(huì)給出足夠提示：

 ? ? ? if(n<3)
 ? ? ? return ? ?//這里少加了一個(gè)分號(hào)
 ? ? ? logrec.data=x[0];
 ? ? ? logrec.time=x[1];
 ? ? ? logrec.code=x[2];

這段代碼的本意是n<3時(shí)程序直接返回，由于程序員的失誤，return少了一個(gè)結(jié)束分號(hào)。編譯器將它翻譯成返回表達(dá)式logrec.data=x[0]的結(jié)果，return后面即使是一個(gè)表達(dá)式也是C語言允許的。這樣當(dāng)n>=3時(shí)，表達(dá)式logrec.data=x[0];就不會(huì)被執(zhí)行，給程序埋下了隱患。

可以毫不客氣的說，弱小的編譯器語義檢查在很大程度上縱容了不可靠代碼可以肆無忌憚的存在。

??????

上文曾提到數(shù)組常常是引起程序不穩(wěn)定的重要因素，程序員往往不經(jīng)意間就會(huì)寫數(shù)組越界。一位同事的代碼在硬件上運(yùn)行，一段時(shí)間后就會(huì)發(fā)現(xiàn)LCD顯示屏上的一個(gè)數(shù)字不正常的被改變。經(jīng)過一段時(shí)間的調(diào)試，問題被定位到下面的一段代碼中：? ?

 ? ? ?int SensorData[30];
 ? ? ? …for(i=30;i>0;i--)
 ? ? ? {
 ? ? ? ? ? ? ?SensorData[i]=…;
 ? ? ? ? ? ? ?…
 ? ? ? }

這里聲明了擁有30個(gè)元素的數(shù)組，不幸的是for循環(huán)代碼中誤用了本不存在的數(shù)組元素SensorData[30]，但C語言卻默許這么使用，并欣然的按照代碼改變了數(shù)組元素SensorData[30]所在位置的值， SensorData[30]所在的位置原本是一個(gè)LCD顯示變量，這正是顯示屏上的那個(gè)值不正常被改變的原因。真慶幸這么輕而易舉的發(fā)現(xiàn)了這個(gè)Bug。

其實(shí)很多編譯器會(huì)對(duì)上述代碼產(chǎn)生一個(gè)警告：賦值超出數(shù)組界限。但并非所有程序員都對(duì)編譯器警告保持足夠敏感，況且，編譯器也并不能檢查出數(shù)組越界的所有情況。舉一個(gè)例子，你在模塊A中定義數(shù)組：

int?SensorData[30];

在模塊B中引用該數(shù)組，但由于你引用代碼并不規(guī)范，這里沒有顯示聲明數(shù)組大小，但編譯器也允許這么做：

extern int?SensorData[];

? ? ? ?如果在模塊B中存在和上面一樣的代碼：

 ? ? ? for(i=30;i>0;i--)
 ? ? ? {
 ? ? ? ? ? ? ?SensorData[i]=…;
 ? ? ? ? ? ? ?…
 ? ? ? }

這次，編譯器不會(huì)給出警告信息，因?yàn)榫幾g器壓根就不知道數(shù)組的元素個(gè)數(shù)。所以，當(dāng)一個(gè)數(shù)組聲明為具有外部鏈接，它的大小應(yīng)該顯式聲明。

再舉一個(gè)編譯器檢查不出數(shù)組越界的例子。函數(shù)func()的形參是一個(gè)數(shù)組形式，函數(shù)代碼簡(jiǎn)化如下所示：

char * func(char SensorData[30])
{
 ? ? ? ? ? ?  unsignedint i；
 ? ? ? ? ? ? ?for(i=30;i>0;i--)
 ? ? ? ? ? ? ?{
 ? ? ? ? ? ? ? ? ? ? SensorData[i]=…;
 ? ? ? ? ? ? ? ? ? ? …
 ? ? ? ? ? ? ?}
}

這個(gè)給SensorData[30]賦初值的語句，編譯器也是不給任何警告的。實(shí)際上，編譯器是將數(shù)組名Sensor隱含的轉(zhuǎn)化為指向數(shù)組第一個(gè)元素的指針，函數(shù)體是使用指針的形式來訪問數(shù)組的，它當(dāng)然也不會(huì)知道數(shù)組元素的個(gè)數(shù)了。造成這種局面的原因之一是C編譯器的作者們認(rèn)為指針代替數(shù)組可以提高程序效率，而且，還可以簡(jiǎn)化編譯器的復(fù)雜度。

指針和數(shù)組是容易給程序造成混亂的，我們有必要仔細(xì)的區(qū)分它們的不同。其實(shí)換一個(gè)角度想想，它們也是容易區(qū)分的：可以將數(shù)組名等同于指針的情況有且只有一處，就是上面例子提到的數(shù)組作為函數(shù)形參時(shí)。其它時(shí)候，數(shù)組名是數(shù)組名，指針是指針。

下面的例子編譯器同樣檢查不出數(shù)組越界。

我們常常用數(shù)組來緩存通訊中的一幀數(shù)據(jù)。在通訊中斷中將接收的數(shù)據(jù)保存到數(shù)組中，直到一幀數(shù)據(jù)完全接收后再進(jìn)行處理。即使定義的數(shù)組長度足夠長，接收數(shù)據(jù)的過程中也可能發(fā)生數(shù)組越界，特別是干擾嚴(yán)重時(shí)。這是由于外界的干擾破壞了數(shù)據(jù)幀的某些位，對(duì)一幀的數(shù)據(jù)長度判斷錯(cuò)誤，接收的數(shù)據(jù)超出數(shù)組范圍，多余的數(shù)據(jù)改寫與數(shù)組相鄰的變量，造成系統(tǒng)崩潰。由于中斷事件的異步性，這類數(shù)組越界編譯器無法檢查到。

如果局部數(shù)組越界，可能引發(fā)ARM架構(gòu)硬件異常。同事的一個(gè)設(shè)備用于接收無線傳感器的數(shù)據(jù)，一次軟件升級(jí)后，發(fā)現(xiàn)接收設(shè)備工作一段時(shí)間后會(huì)死機(jī)。調(diào)試表明ARM7處理器發(fā)生了硬件異常，異常處理代碼是一段死循環(huán)（死機(jī)的直接原因）。接收設(shè)備有一個(gè)硬件模塊用于接收無線傳感器的整包數(shù)據(jù)并存在自己的硬件緩沖區(qū)中，當(dāng)一幀數(shù)據(jù)接收完成后，使用外部中斷通知設(shè)備取數(shù)據(jù)，外部中斷服務(wù)程序精簡(jiǎn)后如下所示：

 ? ? ? __irq ExintHandler(void)
 ? ? ? {
 ? ? ? ? ? ? ?unsignedchar DataBuf[50];
 ? ? ? ? ? ? ?GetData(DataBug); ? ? ? ?//從硬件緩沖區(qū)取一幀數(shù)據(jù)
 ? ? ? ? ? ? ?…
 ? ? ? }

由于存在多個(gè)無線傳感器近乎同時(shí)發(fā)送數(shù)據(jù)的可能加之GetData()函數(shù)保護(hù)力度不夠，數(shù)組DataBuf在取數(shù)據(jù)過程中發(fā)生越界。由于數(shù)組DataBuf為局部變量，被分配在堆棧中，同在此堆棧中的還有中斷發(fā)生時(shí)的運(yùn)行環(huán)境以及中斷返回地址。溢出的數(shù)據(jù)將這些數(shù)據(jù)破壞掉，中斷返回時(shí)PC指針可能變成一個(gè)不合法值，硬件異常由此產(chǎn)生。

如果我們精心設(shè)計(jì)溢出部分的數(shù)據(jù)，化數(shù)據(jù)為指令，就可以利用數(shù)組越界來修改PC指針的值，使之指向我們希望執(zhí)行的代碼。1988年，第一個(gè)網(wǎng)絡(luò)蠕蟲在一天之內(nèi)感染了2000到6000臺(tái)計(jì)算機(jī)，這個(gè)蠕蟲程序利用的正是一個(gè)標(biāo)準(zhǔn)輸入庫函數(shù)的數(shù)組越界Bug。起因是一個(gè)標(biāo)準(zhǔn)輸入輸出庫函數(shù)gets()，原來設(shè)計(jì)為從數(shù)據(jù)流中獲取一段文本，遺憾的是，gets()函數(shù)沒有規(guī)定輸入文本的長度。gets()函數(shù)內(nèi)部定義了一個(gè)500字節(jié)的數(shù)組，攻擊者發(fā)送了大于500字節(jié)的數(shù)據(jù)，利用溢出的數(shù)據(jù)修改了堆棧中的PC指針，從而獲取了系統(tǒng)權(quán)限。

??????

一個(gè)程序模塊通常由兩個(gè)文件組成，源文件和頭文件。如果你在源文件定義變量：

unsigned int?a;

并在頭文件中聲明該變量：extern unsigned long?a;

編譯器會(huì)提示一個(gè)語法錯(cuò)誤：變量’a’聲明類型不一致。但如果你在源文件定義變量：

volatile unsigned int?a，

在頭文件中聲明變量：extern unsigned int?a;?????/*缺少volatile限定符*/

? ? ? ?

編譯器卻不會(huì)給出錯(cuò)誤信息（有些編譯器僅給出一條警告）。這里volatile屬于類型限定符，另一個(gè)常見的類型限定符是const關(guān)鍵字。限定符volatile在嵌入式軟件中至關(guān)重要，用來告訴編譯器不要優(yōu)化它修飾的變量。這里舉一個(gè)刻意構(gòu)造出的例子，因?yàn)楝F(xiàn)實(shí)中的volatile使用Bug大都隱含且難以理解。

???????

在模塊A的源文件中，定義變量：

volatile unsigned int?TimerCount=0;

該變量用來在一個(gè)定時(shí)器服務(wù)程序中進(jìn)行軟件計(jì)時(shí)：

?????? ?????? TimerCount++;???????????? ??????????????//讀取IO端口1的值

?????? 在模塊A的頭文件中，聲明變量：

extern unsigned int?TimerCount;???//這里漏掉了類型限定符volatile

?????? 在模塊B中，要使用TimerCount變量進(jìn)行精確的軟件延時(shí)：

 ? ? ? ? ? ? ?#include “...A.h” ? //首先包含模塊A的頭文件
 ? ? ? ? ? ? ?…
 ? ? ? ? ? ? ?TimerCount=0;
 ? ? ? ? ? ? ?while(TimerCount>=TIMER_VALUE); ? ? ?//延時(shí)一段時(shí)間
 ? ? ? ? ? ? ?…

實(shí)際上，這是一個(gè)死循環(huán)。由于模塊A頭文件中聲明變量TimerCount時(shí)漏掉了volatile限定符，在模塊B中，變量TimerCount是被當(dāng)作unsigned int類型變量。由于寄存器速度遠(yuǎn)快于RAM，編譯器在使用非volatile限定變量時(shí)是先將變量從RAM中拷貝到寄存器中，如果同一個(gè)代碼塊再次用到該變量，就不再從RAM中拷貝數(shù)據(jù)而是直接使用之前寄存器備份值。代碼while(TimerCount>=TIMER_VALUE)中，變量TimerCount僅第一次執(zhí)行時(shí)被使用，之后都是使用的寄存器備份值，而這個(gè)寄存器值一直為0，所以程序無限循環(huán)。下面的流程圖說明了程序使用限定符volatile和不使用volatile的執(zhí)行過程。

? ? ? ?

ARM架構(gòu)下的編譯器會(huì)頻繁的使用堆棧，堆棧用于存儲(chǔ)函數(shù)的返回值、AAPCS規(guī)定的必須保護(hù)的寄存器以及局部變量，包括局部數(shù)組、結(jié)構(gòu)體、聯(lián)合體和C++的類。從堆棧中分配的局部變量的初值是不確定的，因此需要運(yùn)行時(shí)顯式初始化該變量。一旦離開局部變量的作用域，這個(gè)變量立即被釋放，其它代碼也就可以使用它，因此堆棧中的一個(gè)內(nèi)存位置可能對(duì)應(yīng)整個(gè)程序的多個(gè)變量。

???????

局部變量必須顯式初始化，除非你確定知道你要做什么。下面的代碼得到的溫度值跟預(yù)期會(huì)有很大差別，因?yàn)樵谑褂镁植孔兞縮um時(shí)，并不能保證它的初值為0。編譯器會(huì)在第一次運(yùn)行時(shí)清零堆棧區(qū)域，這加重了此類Bug的隱蔽性。

 ? ? ? unsigned intGetTempValue(void)
 ? ? ? {
 ? ? ? ? ? ? ?unsigned int sum; ? ? ? ? ? ? ? ? ? ? ? //定義局部變量，保存總值
 ? ? ? ? ? ? ?for(i=0;i<10;i++)
 ? ? ? ? ? ? ?{
 ? ? ? ? ? ? ? ? ? ? sum+=CollectTemp(); ? ? ? ? ? ? ? //函數(shù)CollectTemp可以得到當(dāng)前的溫度值
 ? ? ? }
 ? ? ? return (sum/10);
 ? ? ? }

由于一旦程序離開局部變量的作用域即被釋放，所以下面代碼返回指向局部變量的指針是沒有實(shí)際意義的，該指針指向的區(qū)域可能會(huì)被其它程序使用，其值會(huì)被改變。

 ? ? ? char * GetData(void)
 ? ? ? {
 ? ? ? ? ? ? ?char buffer[100]; ? ? ? ? ? ? ? ? //局部數(shù)組
 ? ? ? ? ? ? ?…
 ? ? ? ? ? ? ?return buffer;
 ? ? ? }

讓人欣慰的是，現(xiàn)在越來越多的編譯器意識(shí)到了語義檢查的重要性，編譯器的語義檢查也越來越強(qiáng)大，比如著名的Keil MDK編譯器在其 V4.47或以上版本中增加了動(dòng)態(tài)語法檢查并加強(qiáng)了語義檢查，可以友好的提示更多警告信息。

C語言有32個(gè)關(guān)鍵字，卻有34個(gè)運(yùn)算符。要記住所有運(yùn)算符的優(yōu)先級(jí)是困難的。不合理的#define會(huì)加重優(yōu)先級(jí)問題，讓問題變得更加隱蔽。

 ? ? ? #define READSDA ? ? ? IO0PIN&(1<<11) ? ? ? ? ? ?//定義宏，讀IO口p0.11的端口狀態(tài)
 ? ? ? ? ? ? ?//判斷端口p0.11是否為高電平
 ? ? ? if(READSDA==(1<<11)) ?
 ? ? ? { ?
 ? ? ? ? ? ? ?…
 ? ? ? }

?????? 編譯器在編譯后將宏帶入,原if語句變?yōu)?

 ? ? ? if(IO0PIN&(1<<11) ==(1<<11))
 ? ? ? {
 ? ? ? ? ? ? ? ? ? ? …
 ? ? ? }

運(yùn)算符'=='的優(yōu)先級(jí)是大于'&'的，代碼IO0PIN&(1<<11)?==(1<<11))等效為IO0PIN&0x00000001：判斷端口P0.0是否為高電平，這與原意相差甚遠(yuǎn)。

為了制造更多的軟件Bug，C語言的運(yùn)算符當(dāng)然不會(huì)只止步于數(shù)目繁多。在此基礎(chǔ)上，按照常規(guī)方式使用時(shí)，可能引起誤會(huì)的運(yùn)算符更是比比皆是！如下表所示：

1.4 隱式轉(zhuǎn)換和強(qiáng)制轉(zhuǎn)換

這又是C語言的一大詭異之處，它造成的危害程度與數(shù)組和指針有的一拼。語句或表達(dá)式通常應(yīng)該只使用一種類型的變量和常量。然而，如果你混合使用類型，C使用一個(gè)規(guī)則集合來自動(dòng)完成類型轉(zhuǎn)換。這可能很方便，但也很危險(xiǎn)。

a.當(dāng)出現(xiàn)在表達(dá)式里時(shí)，有符號(hào)和無符號(hào)的char和short類型都將自動(dòng)被轉(zhuǎn)換為int類型，在需要的情況下，將自動(dòng)被轉(zhuǎn)換為unsigned int（在short和int具有相同大小時(shí)）。這稱為類型提升。提升在算數(shù)運(yùn)算中通常不會(huì)有什么大的壞處，但如果位運(yùn)算符 ~ 和 << 應(yīng)用在基本類型為unsigned char或unsigned short 的操作數(shù)，結(jié)果應(yīng)該立即強(qiáng)制轉(zhuǎn)換為unsigned char或者unsigned short類型（取決于操作時(shí)使用的類型）。

 ? ? ? uint8_t ?port =0x5aU;
 ? ? ? uint8_t ?result_8;
 ? ? ? result_8= (~port) >> 4;

假如我們不了解表達(dá)式里的類型提升，認(rèn)為在運(yùn)算過程中變量port一直是unsigned char類型的。我們來看一下運(yùn)算過程：~port結(jié)果為0xa5，0xa5>>4結(jié)果為0x0a，這是我們期望的值。但實(shí)際上，result_8的結(jié)果卻是0xfa！在ARM結(jié)構(gòu)下，int類型為32位。變量port在運(yùn)算前被提升為int類型：~port結(jié)果為0xffffffa5，0xa5>>4結(jié)果為0x0ffffffa，賦值給變量result_8，發(fā)生類型截?cái)啵ㄟ@也是隱式的！），result_8=0xfa。經(jīng)過這么詭異的隱式轉(zhuǎn)換，結(jié)果跟我們期望的值，已經(jīng)大相徑庭！正確的表達(dá)式語句應(yīng)該為：

?????? result_8=(unsigned char) (~port) >> 4;?????????????/*強(qiáng)制轉(zhuǎn)換*/

b.在包含兩種數(shù)據(jù)類型的任何運(yùn)算里，兩個(gè)值都會(huì)被轉(zhuǎn)換成兩種類型里較高的級(jí)別。類型級(jí)別從高到低的順序是long double、double、float、unsigned long long、long long、unsigned long、long、unsigned int、int。這種類型提升通常都是件好事，但往往有很多程序員不能真正理解這句話，從而做一些想當(dāng)然的事情，比如下面的例子，int類型表示16位。

 ? ? ? uint16_t ?u16a = 40000; ? ? ? ? ? ?/* 16位無符號(hào)變量*/
 ? ? ? uint16_t ?u16b= 30000; ? ? ? ? ?/*16位無符號(hào)變量*/
 ? ? ? uint32_t ?u32x; ? ? ? ? ? ? ? ? ? ? ? ?/*32位無符號(hào)變量 */
 ? ? ? uint32_t ?u32y;
 ? ? ? u32x = u16a +u16b; ? ? ? ? ? ? ? ?/* u32x = 70000還是4464 ? */
 ? ? ? u32y =(uint32_t)(u16a + u16b); ? /* u32y = 70000 還是4464 ? */

u32x和u32y的結(jié)果都是4464（70000%65536）！不要認(rèn)為表達(dá)式中有一個(gè)高類別uint32_t類型變量，編譯器都會(huì)幫你把所有其他低類別都提升到uint32_t類型。正確的書寫方式：

 ? ? ? ? ? ? ? ? ?  u32x = (uint32_t)u16a +(uint32_t)u16b;或者：
 ? ? ? ? ? ? ? ? ? ?u32x = (uint32_t)u16a + u16b;

后一種寫法在本表達(dá)式中是正確的，但是在其它表達(dá)式中不一定正確，比如：

 ? ? ? ? ? ? ? ? ? uint16_t u16a,u16b,u16c;
 ? ? ? ? ? ? ? ? ? uint32_t ?u32x;
 ? ? ? ? ? ? ? ? ? u32x= u16a + u16b + (uint32_t)u16c;/*錯(cuò)誤寫法，u16a+ u16b仍可能溢出*/

c.在賦值語句里，計(jì)算的最后結(jié)果被轉(zhuǎn)換成將要被賦予值得那個(gè)變量的類型。這一過程可能導(dǎo)致類型提升也可能導(dǎo)致類型降級(jí)。降級(jí)可能會(huì)導(dǎo)致問題。比如將運(yùn)算結(jié)果為321的值賦值給8位char類型變量。程序必須對(duì)運(yùn)算時(shí)的數(shù)據(jù)溢出做合理的處理。

很多其他語言，像Pascal語言（好笑的是C語言設(shè)計(jì)者之一曾撰文狠狠批評(píng)過Pascal語言），都不允許混合使用類型，但C語言不會(huì)限制你的自由，即便這經(jīng)常引起B(yǎng)ug。

d.當(dāng)作為函數(shù)的參數(shù)被傳遞時(shí)，char和short會(huì)被轉(zhuǎn)換為int，float會(huì)被轉(zhuǎn)換為double。

e.C語言支持強(qiáng)制類型轉(zhuǎn)換，如果你必須要進(jìn)行強(qiáng)制類型轉(zhuǎn)換時(shí)，要確保你對(duì)類型轉(zhuǎn)換有足夠了解：

• 并非所有強(qiáng)制類型轉(zhuǎn)換都是由風(fēng)險(xiǎn)的，把一個(gè)整數(shù)值轉(zhuǎn)換為一種具有相同符號(hào)的更寬類型時(shí)，是絕對(duì)安全的。

• 精度高的類型強(qiáng)制轉(zhuǎn)換為精度低的類型時(shí)，通過丟棄適當(dāng)數(shù)量的最高有效位來獲取結(jié)果，也就是說會(huì)發(fā)生數(shù)據(jù)截?cái)?，并且可能改變?shù)據(jù)的符號(hào)位。

• ?精度低的類型強(qiáng)制轉(zhuǎn)換為精度高的類型時(shí)，如果兩種類型具有相同的符號(hào)，那么沒什么問題；需要注意的是負(fù)的有符號(hào)精度低類型強(qiáng)制轉(zhuǎn)換為無符號(hào)精度高類型時(shí)，會(huì)不直觀的執(zhí)行符號(hào)擴(kuò)展，例如：

unsigned int bob;
signed char fred = -1;
 
bob=(unsigned int )fred; ? ? ? ? ? ? ?/*發(fā)生符號(hào)擴(kuò)展，此時(shí)bob為0xFFFFFFFF*/

一些編程建議：

• ?深入理解嵌入式C語言以及編譯器

• ?細(xì)致、謹(jǐn)慎的編程

• 使用好的風(fēng)格和合理的設(shè)計(jì)

• 不要倉促編寫代碼，寫每一行的代碼時(shí)都要三思而后行：可能會(huì)出現(xiàn)什么樣的錯(cuò)誤？是否考慮了所有的邏輯分支？

• 打開編譯器所有警告開關(guān)

• 使用靜態(tài)分析工具分析代碼

• 安全的讀寫數(shù)據(jù)（檢查所有數(shù)組邊界…）

• 檢查指針的合法性

• 檢查函數(shù)入口參數(shù)合法性

• 檢查所有返回值

• 在聲明變量位置初始化所有變量

• 合理的使用括號(hào)

• 謹(jǐn)慎的進(jìn)行強(qiáng)制轉(zhuǎn)換

• 使用好的診斷信息日志和工具