本人工作中維護著(zhù)一個(gè)基于嵌入式Linux的一份SIP協(xié)議棧。一年多來(lái)，有如下心得：
(1)非常熟悉你維護的代碼，并且為它的體系結構、各個(gè)模塊（含Makefile之類(lèi)的軟件構建配置文件）、重要函數、重要CASE編寫(xiě)文檔。使用Source-Navigator之類(lèi)的工具高效地瀏覽整個(gè)工程，理清體系結構、調用關(guān)系。
(2)嵌入式軟件測試技巧：一是要做單元測試、集成測試、系統測試（系統測試是黑盒的，可以用Python腳本自動(dòng)化一些測試用例）。二是努力讓整個(gè)軟件盡量少地修改（不需要修改一行代碼，只改Makefile中的CC/AR等平臺相關(guān)的設置）就完整地運行在Linux PC上。在DDD或gdb中以單步調試、斷點(diǎn)等手段復現BUG后定位和解決BUG非常容易，尤其是“段錯誤”BUG：可以利用DDD或gdb打開(kāi)產(chǎn)生的Core Dump就能獲得段錯誤發(fā)生時(shí)的調用堆棧及所有層次上的環(huán)境信息。用Valgrind檢查軟件的各種內存錯誤（Valgrind在檢查內存非法訪(fǎng)問(wèn)的功能只適用于動(dòng)態(tài)分配的內存，不適用于棧中的內存）。用ltrace/strace查看executable所有的庫調用/系統調用。要是以上措施都搞不定BUG，那就老老實(shí)實(shí)地用printf或日志吧。
(3)熟悉C語(yǔ)言的常見(jiàn)的陷阱，如：[1]任何兩整數加/減/乘都可能溢出，尤其當心兩無(wú)符號型減法/乘法以及無(wú)符號與有符號的混合運算（不要為了減少編譯器的警告就不加思索地做強之類(lèi)性轉換）。[2]strncpy/malloc等函數的規格要清楚，它們都有一些使用的注意事項。熟悉這些陷阱就能夠主動(dòng)、高效地發(fā)現BUG而不是被動(dòng)、低效地解決BUG。無(wú)論是主動(dòng)還是被動(dòng)，DDD/Valgrind之類(lèi)的工具都有用武之地，但仍然高度依賴(lài)于維護者的經(jīng)驗（主要就是熟悉C語(yǔ)言的常見(jiàn)的陷阱）。這方面一是要多看看《C編程精粹》，《C陷阱與缺陷》之類(lèi)的經(jīng)典書(shū)籍；二是要利用PC-Lint/Splint之類(lèi)的C代碼靜態(tài)檢查工具。
(4)不要輕信別人的代碼和文檔。仔細測試軟件依賴(lài)的那些不屬于你維護范圍的庫（通常是黑盒的）。
(5)熟悉本軟件與其他軟件互通所遵循的標準。SIP之類(lèi)的開(kāi)放標準要直接看標準原文。用戶(hù)定制的互通性要求有時(shí)與標準沖突，要提出來(lái)。避免把軟件改得不倫不類(lèi)。
在我看來(lái)，BUG的起源有3類(lèi)：
(1)自己掉進(jìn)了C語(yǔ)言的陷阱
(2)自己的某些設計邏輯有BUG
(3)別人維護的東西有BUG
《Write Clean Code》經(jīng)典語(yǔ)錄
(1)要從程序中刪去無(wú)定義的特性或者在程序中使用斷言來(lái)檢查出無(wú)定義特性的非法使用。
(2)只要用戶(hù)使用了“<”操作符或其它要用有符號信息的操作符，就迫使編譯程序產(chǎn)生不可移植的代碼。記住一個(gè)原則不要在表達式中使用“簡(jiǎn)單的”字符。由于位域也有同樣的問(wèn)題，因此也有一個(gè)類(lèi)似的原則：任何時(shí)候都不要使用“簡(jiǎn)單的”位域。
(3)經(jīng)常反問(wèn)：“這個(gè)變量表達式會(huì )上溢或下溢嗎？”
(4)有風(fēng)險的慣用語(yǔ)就是這樣一些短語(yǔ)或表達式，它們看上去似乎能夠正確地工作，但實(shí)際上在某些特殊場(chǎng)合下，它們并不能正確執行。C語(yǔ)言就是具有這樣一些慣用語(yǔ)的語(yǔ)言，最好的辦法是：無(wú)論什么時(shí)候，只要有可能就盡量避免使用這些慣用語(yǔ)。在memchr中有風(fēng)險的慣用語(yǔ)是：
pchEnd = pch + size;
while( pch < pchEnd )
…
C語(yǔ)言還有許多其它的有風(fēng)險的慣用語(yǔ)。有個(gè)最好的方法來(lái)找到自己經(jīng)常使用的有風(fēng)險的慣用語(yǔ)，這就是檢查以前出現的每一個(gè)錯誤，再問(wèn)一下自己：“怎樣來(lái)避免這些錯誤？”然后建立個(gè)人的風(fēng)險慣用語(yǔ)表從而避免使用這些慣用語(yǔ)。
《C專(zhuān)家編程》經(jīng)典語(yǔ)錄
(1)對無(wú)符號類(lèi)型的建議
盡量不要在你的代碼中使用無(wú)符號類(lèi)型，一面增加不必要的復雜性。尤其是，不要僅僅因為無(wú)符號數不存在負值（如年齡、國債）而使用它來(lái)表示數量。
盡量使用像int那樣的有符號類(lèi)型，這樣在涉及升級混合類(lèi)型的復雜細節時(shí)，不必擔心邊界情況（如-1被翻譯成非常大的正數）。
只有在使用位段和二進(jìn)制掩碼時(shí)，才可以用無(wú)符號數。應該在表達式中使用強制類(lèi)型轉換，使操作數均為有符號數或者無(wú)符號數，這樣就不必由編譯器來(lái)選擇結果的類(lèi)型。
(2)語(yǔ)言的細節決定了一種語(yǔ)言到底是可靠的還是容易滋生錯誤的。
(3)用lint程序徹查程序的價(jià)值不僅僅在于去除現存的Bug，而且能防止新的Bug污染source base。我們現在要求對源代碼的所有修改或增加必須能通過(guò)lint程序檢查，這樣就能保持程序的lint-clean狀態(tài)。
(4)警惕Interpositioning
Interpositioning就是通過(guò)編寫(xiě)與庫函數同名的函數來(lái)取代該庫函數的行為。不僅你自己所進(jìn)行的所有對該庫函數的調用將被自己版本的函數調用所取代，而且所有調用該庫函數的系統調用也將用你的函數取而代之。當編譯起注意到庫函數被另一個(gè)定義覆蓋時(shí)，它通常不會(huì )給出錯誤信息。這也是遵循C語(yǔ)言的設計哲學(xué)，即程序員所做的都是對的。
絕大多數程序員都沒(méi)有記住C標準庫中所有函數的名字，而且像index或mktemp這樣常見(jiàn)的名字其重復概率之高令人吃驚。有時(shí)候，這方面的Bug會(huì )帶入到產(chǎn)品代碼中去。
準則：不要讓程序中的任何符號成為全局的，除非有意把它們作為程序的接口之一。
(5)UNIX編程常見(jiàn)的兩個(gè)運行時(shí)錯誤：
bus error (core dumped)和segmentation faule (core dumped)
總線(xiàn)錯誤和段錯誤的準確原因在不同的操作系統版本上各不相同。以下描述的是運行于SPARC架構的SunOS出現這兩類(lèi)錯誤以及產(chǎn)生錯誤的原因。
事實(shí)上，總線(xiàn)錯誤幾乎都是由于為對齊的讀或寫(xiě)引起的。它之所以成為總線(xiàn)錯誤，是因為出現未對齊的內存訪(fǎng)問(wèn)請求時(shí)，被堵塞的組件就是地址總線(xiàn)。對齊（alignment）的意思即使數據項只能存儲在數據項大小的整數倍的內存地址上。在現代的計算機架構中，尤其是RISC架構，都需要數據對齊。通過(guò)迫使每個(gè)內存訪(fǎng)問(wèn)局限在一個(gè)Cache行或一個(gè)單獨的頁(yè)面內，可以極大地簡(jiǎn)化（并加速）Cache控制器和內存管理單元這樣的硬件。
union{char a[16];
int i;
}u;
int *p=(int *)&(u.a[1]);
*p=17;/*p中未對齊的地址會(huì )引起一個(gè)總線(xiàn)錯誤！*/
一個(gè)好的編譯器發(fā)現未對齊的情況時(shí)會(huì )發(fā)出警告，但它并不能檢測到所有未對齊的情況。編譯起通過(guò)自動(dòng)分配和填充數據（在內存中）來(lái)進(jìn)行對齊。...當把一個(gè)char指針轉換為int指針時(shí)，就會(huì )出現神秘的總線(xiàn)錯誤。
段錯誤或段違規（segmentation violation）－－在Sun的硬件中，段錯誤是由于內存管理單元（負責支持虛擬內存的硬件）的異常所致，而該異常通常是由于引用一個(gè)為初始化或非法值的指針引起的。
[問(wèn)]pc-lint與linux中的splint有何區別？因為沒(méi)用過(guò)pc-lint，能不能用splint來(lái)代替？
[答]PC-lint是一個(gè)由Gimpel Software提供的支持C/C++的商用程序。
Splint (原來(lái)的 LCLint) 是一個(gè)GNU免費授權的 Lint程序，但是只支持C不支持C++. Splint http://www.splint.org/
在軟件開(kāi)發(fā)過(guò)程中，我們可以利用源碼檢查工具來(lái)找出常見(jiàn)的編程錯誤以及安全漏洞。gcc選項"-Wall -Werror"編譯給出的警告并不夠，并且編譯器版本不同，警告的范圍也不相同！
這些工具用起來(lái)并不復雜，下面介紹splint和flawfinder這兩款源碼檢查工具的使用方法。但需要注意的是，雖然這些工具能夠分擔一部分工作，但卻無(wú)法完全替代人類(lèi)。因為工具在發(fā)現漏洞的同時(shí)，也可能遺漏安全漏洞。
Splint跳過(guò)所有系統頭文件，還發(fā)生解析錯誤，主要有以下原因：
(1)語(yǔ)法不符合C89，例如變量pAlarm定義不在語(yǔ)句塊的開(kāi)頭：
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)數據類(lèi)型或函數是編譯器擴展的，例如__sigset_t應當用sigset_t代替：
sigemptyset((__sigset_t *)&sa.sa_mask);
還有GCC編譯器內建的數據類(lèi)型__built_va_list被GCC作為基本類(lèi)型了...所以，Splint手冊指出系統頭文件一般是不可解析的！要處理GCC所有內建的預處理宏、數據結構、函數很難，Splint郵件列表有人嘗試以這種方式lint linux內核模塊成功了。
可能自編C文件依賴(lài)于include的系統頭文件中某些擴展宏、數據結構、函數聲明，可以自己編寫(xiě)與之同名的頭文件。這個(gè)很容易的：不需要修改工程中任何文件，并且一般寫(xiě)兩三個(gè)很短的頭文件就行了。
(3)Splint的unixlib包括posixlib包括isolib。但都不包含<limits.h>定義的UINT_MAX等宏
Splint的unixlib比posixlib多了（如果用posixlib，自己寫(xiě)的這幾個(gè)同名頭文件似乎就不會(huì )被splint include進(jìn)去？checking macros階段看出來(lái)用上了？）：
[1]<unistd.h>定義的socklen_t,in_addr_t,sa_family_t等類(lèi)型
[2]<sys/select.h>定義的fd_set類(lèi)型和select函數（遵循POSIX 1003.1-2001）。
[3]<pthread.h>定義的pthread_t,pthread_mutex_t等類(lèi)型。但卻有pthread_create等函數聲明。
怎樣查看splint的posixlib庫包含了哪些頭文件？
Splint知道的POSIX規格是IEEE 1003.1-1990，所以不支持之后規格（如IEEE Std 1003.1b-1993）導入的特性，如siginfo_t結構體等。有兩個(gè)辦法解決：[1]干凈的辦法是，更新posix.h后重新生成posix.lcd和posixstric.lcd。Splint手冊第14.2節講述了這方面內容：splint源碼包的lib目錄下就有standard/posix/unix三個(gè)庫的頭文件和lcd文件。按照指示生成一個(gè)lcd文件后，在之后運行splint檢查時(shí)以"-load"選項加載一個(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)自己工程定義的宏沒(méi)有設置好導致語(yǔ)法錯誤...BUG:)
Splint解析錯誤發(fā)生時(shí)，如果一眼看不出原因，可以給splint命令加“+keep”選項使得其保留預處理之后的C文件。GCC的"-E"選項輸出預處理之后的C文件。用以下辦法獲得C預處理器所有預定義的宏：
touch foo.h
cpp -dM foo.h
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1526444
