本人工作中維護(hù)著一個(gè)基于嵌入式Linux的一份SIP協(xié)議棧。一年多來，有如下心得：
(1)非常熟悉你維護(hù)的代碼，并且為它的體系結(jié)構(gòu)、各個(gè)模塊（含Makefile之類的軟件構(gòu)建配置文件）、重要函數(shù)、重要CASE編寫文檔。使用Source-Navigator之類的工具高效地瀏覽整個(gè)工程，理清體系結(jié)構(gòu)、調(diào)用關(guān)系。
(2)嵌入式軟件測試技巧：一是要做單元測試、集成測試、系統(tǒng)測試（系統(tǒng)測試是黑盒的，可以用Python腳本自動(dòng)化一些測試用例）。二是努力讓整個(gè)軟件盡量少地修改（不需要修改一行代碼，只改Makefile中的CC/AR等平臺相關(guān)的設(shè)置）就完整地運(yùn)行在Linux PC上。在DDD或gdb中以單步調(diào)試、斷點(diǎn)等手段復(fù)現(xiàn)BUG后定位和解決BUG非常容易，尤其是“段錯(cuò)誤”BUG：可以利用DDD或gdb打開產(chǎn)生的Core Dump就能獲得段錯(cuò)誤發(fā)生時(shí)的調(diào)用堆棧及所有層次上的環(huán)境信息。用Valgrind檢查軟件的各種內(nèi)存錯(cuò)誤（Valgrind在檢查內(nèi)存非法訪問的功能只適用于動(dòng)態(tài)分配的內(nèi)存，不適用于棧中的內(nèi)存）。用ltrace/strace查看executable所有的庫調(diào)用/系統(tǒng)調(diào)用。要是以上措施都搞不定BUG，那就老老實(shí)實(shí)地用printf或日志吧。
(3)熟悉C語言的常見的陷阱，如：[1]任何兩整數(shù)加/減/乘都可能溢出，尤其當(dāng)心兩無符號型減法/乘法以及無符號與有符號的混合運(yùn)算（不要為了減少編譯器的警告就不加思索地做強(qiáng)之類性轉(zhuǎn)換）。[2]strncpy/malloc等函數(shù)的規(guī)格要清楚，它們都有一些使用的注意事項(xiàng)。熟悉這些陷阱就能夠主動(dòng)、高效地發(fā)現(xiàn)BUG而不是被動(dòng)、低效地解決BUG。無論是主動(dòng)還是被動(dòng)，DDD/Valgrind之類的工具都有用武之地，但仍然高度依賴于維護(hù)者的經(jīng)驗(yàn)（主要就是熟悉C語言的常見的陷阱）。這方面一是要多看看《C編程精粹》，《C陷阱與缺陷》之類的經(jīng)典書籍；二是要利用PC-Lint/Splint之類的C代碼靜態(tài)檢查工具。
(4)不要輕信別人的代碼和文檔。仔細(xì)測試軟件依賴的那些不屬于你維護(hù)范圍的庫（通常是黑盒的）。
(5)熟悉本軟件與其他軟件互通所遵循的標(biāo)準(zhǔn)。SIP之類的開放標(biāo)準(zhǔn)要直接看標(biāo)準(zhǔn)原文。用戶定制的互通性要求有時(shí)與標(biāo)準(zhǔn)沖突，要提出來。避免把軟件改得不倫不類。

在我看來，BUG的起源有3類：
(1)自己掉進(jìn)了C語言的陷阱
(2)自己的某些設(shè)計(jì)邏輯有BUG
(3)別人維護(hù)的東西有BUG

《Write Clean Code》經(jīng)典語錄
(1)要從程序中刪去無定義的特性或者在程序中使用斷言來檢查出無定義特性的非法使用。
(2)只要用戶使用了“<”操作符或其它要用有符號信息的操作符，就迫使編譯程序產(chǎn)生不可移植的代碼。記住一個(gè)原則不要在表達(dá)式中使用“簡單的”字符。由于位域也有同樣的問題，因此也有一個(gè)類似的原則：任何時(shí)候都不要使用“簡單的”位域。
(3)經(jīng)常反問：“這個(gè)變量表達(dá)式會上溢或下溢嗎？”
(4)有風(fēng)險(xiǎn)的慣用語就是這樣一些短語或表達(dá)式，它們看上去似乎能夠正確地工作，但實(shí)際上在某些特殊場合下，它們并不能正確執(zhí)行。C語言就是具有這樣一些慣用語的語言，最好的辦法是：無論什么時(shí)候，只要有可能就盡量避免使用這些慣用語。在memchr中有風(fēng)險(xiǎn)的慣用語是：
pchEnd = pch + size;
while( pch < pchEnd )
…
C語言還有許多其它的有風(fēng)險(xiǎn)的慣用語。有個(gè)最好的方法來找到自己經(jīng)常使用的有風(fēng)險(xiǎn)的慣用語，這就是檢查以前出現(xiàn)的每一個(gè)錯(cuò)誤，再問一下自己：“怎樣來避免這些錯(cuò)誤？”然后建立個(gè)人的風(fēng)險(xiǎn)慣用語表從而避免使用這些慣用語。

《C專家編程》經(jīng)典語錄
(1)對無符號類型的建議
盡量不要在你的代碼中使用無符號類型，一面增加不必要的復(fù)雜性。尤其是，不要僅僅因?yàn)闊o符號數(shù)不存在負(fù)值（如年齡、國債）而使用它來表示數(shù)量。
盡量使用像int那樣的有符號類型，這樣在涉及升級混合類型的復(fù)雜細(xì)節(jié)時(shí)，不必?fù)?dān)心邊界情況（如-1被翻譯成非常大的正數(shù)）。
只有在使用位段和二進(jìn)制掩碼時(shí)，才可以用無符號數(shù)。應(yīng)該在表達(dá)式中使用強(qiáng)制類型轉(zhuǎn)換，使操作數(shù)均為有符號數(shù)或者無符號數(shù)，這樣就不必由編譯器來選擇結(jié)果的類型。
(2)語言的細(xì)節(jié)決定了一種語言到底是可靠的還是容易滋生錯(cuò)誤的。
(3)用lint程序徹查程序的價(jià)值不僅僅在于去除現(xiàn)存的Bug，而且能防止新的Bug污染source base。我們現(xiàn)在要求對源代碼的所有修改或增加必須能通過lint程序檢查，這樣就能保持程序的lint-clean狀態(tài)。
(4)警惕Interpositioning
Interpositioning就是通過編寫與庫函數(shù)同名的函數(shù)來取代該庫函數(shù)的行為。不僅你自己所進(jìn)行的所有對該庫函數(shù)的調(diào)用將被自己版本的函數(shù)調(diào)用所取代，而且所有調(diào)用該庫函數(shù)的系統(tǒng)調(diào)用也將用你的函數(shù)取而代之。當(dāng)編譯起注意到庫函數(shù)被另一個(gè)定義覆蓋時(shí)，它通常不會給出錯(cuò)誤信息。這也是遵循C語言的設(shè)計(jì)哲學(xué)，即程序員所做的都是對的。
絕大多數(shù)程序員都沒有記住C標(biāo)準(zhǔn)庫中所有函數(shù)的名字，而且像index或mktemp這樣常見的名字其重復(fù)概率之高令人吃驚。有時(shí)候，這方面的Bug會帶入到產(chǎn)品代碼中去。
準(zhǔn)則：不要讓程序中的任何符號成為全局的，除非有意把它們作為程序的接口之一。
(5)UNIX編程常見的兩個(gè)運(yùn)行時(shí)錯(cuò)誤：
bus error (core dumped)和segmentation faule (core dumped)
總線錯(cuò)誤和段錯(cuò)誤的準(zhǔn)確原因在不同的操作系統(tǒng)版本上各不相同。以下描述的是運(yùn)行于SPARC架構(gòu)的SunOS出現(xiàn)這兩類錯(cuò)誤以及產(chǎn)生錯(cuò)誤的原因。
事實(shí)上，總線錯(cuò)誤幾乎都是由于為對齊的讀或?qū)懸鸬?。它之所以成為總線錯(cuò)誤，是因?yàn)槌霈F(xiàn)未對齊的內(nèi)存訪問請求時(shí)，被堵塞的組件就是地址總線。對齊（alignment）的意思即使數(shù)據(jù)項(xiàng)只能存儲在數(shù)據(jù)項(xiàng)大小的整數(shù)倍的內(nèi)存地址上。在現(xiàn)代的計(jì)算機(jī)架構(gòu)中，尤其是RISC架構(gòu)，都需要數(shù)據(jù)對齊。通過迫使每個(gè)內(nèi)存訪問局限在一個(gè)Cache行或一個(gè)單獨(dú)的頁面內(nèi)，可以極大地簡化（并加速）Cache控制器和內(nèi)存管理單元這樣的硬件。
union{char a[16];
int i;
}u;
int *p=(int *)&(u.a[1]);
*p=17;/*p中未對齊的地址會引起一個(gè)總線錯(cuò)誤！*/
一個(gè)好的編譯器發(fā)現(xiàn)未對齊的情況時(shí)會發(fā)出警告，但它并不能檢測到所有未對齊的情況。編譯起通過自動(dòng)分配和填充數(shù)據(jù)（在內(nèi)存中）來進(jìn)行對齊。...當(dāng)把一個(gè)char指針轉(zhuǎn)換為int指針時(shí)，就會出現(xiàn)神秘的總線錯(cuò)誤。
段錯(cuò)誤或段違規(guī)（segmentation violation）－－在Sun的硬件中，段錯(cuò)誤是由于內(nèi)存管理單元（負(fù)責(zé)支持虛擬內(nèi)存的硬件）的異常所致，而該異常通常是由于引用一個(gè)為初始化或非法值的指針引起的。


[問]pc-lint與linux中的splint有何區(qū)別？因?yàn)闆]用過pc-lint，能不能用splint來代替？
[答]PC-lint是一個(gè)由Gimpel Software提供的支持C/C++的商用程序。
Splint (原來的 LCLint) 是一個(gè)GNU免費(fèi)授權(quán)的 Lint程序，但是只支持C不支持C++. Splint http://www./
在軟件開發(fā)過程中，我們可以利用源碼檢查工具來找出常見的編程錯(cuò)誤以及安全漏洞。gcc選項(xiàng)"-Wall -Werror"編譯給出的警告并不夠，并且編譯器版本不同，警告的范圍也不相同！
這些工具用起來并不復(fù)雜，下面介紹splint和flawfinder這兩款源碼檢查工具的使用方法。但需要注意的是，雖然這些工具能夠分擔(dān)一部分工作，但卻無法完全替代人類。因?yàn)楣ぞ咴诎l(fā)現(xiàn)漏洞的同時(shí)，也可能遺漏安全漏洞。

Splint跳過所有系統(tǒng)頭文件，還發(fā)生解析錯(cuò)誤，主要有以下原因：
(1)語法不符合C89，例如變量pAlarm定義不在語句塊的開頭：
    if (g_oMDAlarmStatus == EVENT_ALERT){
        g_oMDAlarmStatus = EVENT_ALARM;
        Alarm* pAlarm=(Alarm*)malloc(sizeof(Alarm));
        pAlarm->intSignal=SIG_SIGUSR2;
          EvtNotify(pAlarm);
        printf("sigusr2(): Called EvtNotifyMain\n");
    }
(2)數(shù)據(jù)類型或函數(shù)是編譯器擴(kuò)展的，例如__sigset_t應(yīng)當(dāng)用sigset_t代替：
  sigemptyset((__sigset_t *)&sa.sa_mask);
還有GCC編譯器內(nèi)建的數(shù)據(jù)類型__built_va_list被GCC作為基本類型了...所以，Splint手冊指出系統(tǒng)頭文件一般是不可解析的！要處理GCC所有內(nèi)建的預(yù)處理宏、數(shù)據(jù)結(jié)構(gòu)、函數(shù)很難，Splint郵件列表有人嘗試以這種方式lint linux內(nèi)核模塊成功了。
可能自編C文件依賴于include的系統(tǒng)頭文件中某些擴(kuò)展宏、數(shù)據(jù)結(jié)構(gòu)、函數(shù)聲明，可以自己編寫與之同名的頭文件。這個(gè)很容易的：不需要修改工程中任何文件，并且一般寫兩三個(gè)很短的頭文件就行了。
(3)Splint的unixlib包括posixlib包括isolib。但都不包含<limits.h>定義的UINT_MAX等宏
Splint的unixlib比posixlib多了（如果用posixlib，自己寫的這幾個(gè)同名頭文件似乎就不會被splint include進(jìn)去？checking macros階段看出來用上了？）：
[1]<unistd.h>定義的socklen_t,in_addr_t,sa_family_t等類型
[2]<sys/select.h>定義的fd_set類型和select函數(shù)（遵循POSIX 1003.1-2001）。
[3]<pthread.h>定義的pthread_t,pthread_mutex_t等類型。但卻有pthread_create等函數(shù)聲明。
怎樣查看splint的posixlib庫包含了哪些頭文件？
Splint知道的POSIX規(guī)格是IEEE 1003.1-1990，所以不支持之后規(guī)格（如IEEE Std 1003.1b-1993）導(dǎo)入的特性，如siginfo_t結(jié)構(gòu)體等。有兩個(gè)辦法解決：[1]干凈的辦法是，更新posix.h后重新生成posix.lcd和posixstric.lcd。Splint手冊第14.2節(jié)講述了這方面內(nèi)容：splint源碼包的lib目錄下就有standard/posix/unix三個(gè)庫的頭文件和lcd文件。按照指示生成一個(gè)lcd文件后，在之后運(yùn)行splint檢查時(shí)以"-load"選項(xiàng)加載一個(gè)自己創(chuàng)建的lcd（注意：最多只能加載一個(gè)自己創(chuàng)建的lcd）。[2]As a quick-and-dirty solution, you could provide a dummy definition for siginfo_t.
(4)自己工程定義的宏沒有設(shè)置好導(dǎo)致語法錯(cuò)誤...BUG:)

Splint解析錯(cuò)誤發(fā)生時(shí)，如果一眼看不出原因，可以給splint命令加“+keep”選項(xiàng)使得其保留預(yù)處理之后的C文件。GCC的"-E"選項(xiàng)輸出預(yù)處理之后的C文件。用以下辦法獲得C預(yù)處理器所有預(yù)定義的宏：
touch foo.h
cpp -dM foo.h

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1526444