第3部分 軟體研發工作總結
VC++內建開發環境中Linux下Pclint工程的配置方法及常見錯誤修改
【文章摘要】
Pclint是一種C/C++軟體代碼靜态分析工具。它是一種更加嚴格的編譯器，能夠發現普通編譯器所不能發現的代碼中的很多問題，是以被廣泛應用于軟體開發項目中。
本文介紹了如何在VC++內建開發環境中配置Linux下的Pclint工程，給出了C語言中pclint規則A檢查的常見錯誤，并描述了對應的修改辦法。
【關鍵詞】
VC++ Pclint 配置 操作 修改
1. 前言
Pclint是一種強大的C/C++軟體代碼靜态分析工具，它不但能夠對程式進行全局分析、識别沒有被适當檢驗的數組下标、報告未被初始化的變量、警告使用空指針連同備援的代碼，還能夠有效地提出許多程式在空間利用、運作效率上的改進點。是以，許多大型的軟體研發組織都把Pclint檢查作為代碼走查的第一道工序。
Pclint的作用有如下幾個：
(1) Pclint是一種更加嚴格的編譯器，不僅可以像普通編譯器那樣檢查出一般的文法錯誤，還可以檢查出那些雖然完全合乎文法要求，但很可能是潛在的、不易發現的錯誤。
(2) Pclint不但可以檢測單個檔案，也可以從整個項目的角度來檢測問題。
(3) Pclint支援幾乎所有流行的編輯環境和編譯器。
(4) Pclint還支援各種提高效率和防止錯誤的方法。
Pclint雖然好處多多，但要運作起來還需要進行一定的配置，而這個配置過程比較的繁瑣，稍不注意就會配錯。
本文根據作者的實際經驗，介紹了VC++內建開發環境中Linux下Pclint工程的配置方法。在配置之前，要確定已經擷取了完整的Pclint軟體，并存放到PC機上。
此外，本文還介紹了用pclint工具對C代碼進行檢查的時候，規則A中的常見錯誤，并給出了對應的修改辦法。
2. 配置前準備
2.1 擷取Linux的include和lib目錄
為了完成Linux下Pclint工程的配置，需要将Linux下的include和lib目錄存放在本地檔案夾下。
一般說來，這兩個目錄位于usr目錄之下，在本地的存放情況如圖1所示：
圖1 include和lib的本地存放示意圖
2.2 A規則和B規則lnt檔案的配置
Pclint對代碼的檢查分為A規則和B規則，其中A規則是必須要修改的，B規則中與平台無關的錯誤要盡量修改。A規則和B規則配置檔案的示例如下：
A規則：
au-sm.lnt au-ds.lnt au-misra.lnt co-gnu3.lnt lib-stl.lnt
options_A.lnt -si4 -sp4
-i"D:/linux/usr/include"
-i"D:/linux/usr/lib/gcc-lib/i586-linux/3.3.3/include"
B規則：
options_B.lnt -si4 -sp4
根據include和lib目錄存放位置的不同，隻需在兩個檔案中作對應修改即可。
2.3 Pclint檢查結果檔案夾的建立
為了友善儲存Pclint的檢查結果，需要在本地建立一個檔案夾。當每次運作Pclint之後，會将結果存放在該檔案夾之下。
檔案夾及産生的結果示例如圖2所示：
圖2 Pclint檢查結果存放檔案夾示意圖
3. VC++中Pclint工程的配置方法
在完成了上述準備工作之後，我們接下來要做的便是在VC++中配置Pclint工程了。
3.1 Pclint規則A的配置
打開VC++軟體，選擇“Tools”-->“Customize”。如圖3所示：
圖3 Pclint規則A的配置操作1
單擊“Customize”，選擇“Tools”。如圖4所示：
圖4 Pclint規則A的配置操作2
在“Tools”菜單下，可以完成Pclint規則A的配置。配置示意圖如圖5所示：
圖5 Pclint規則A的配置操作3
Pclint規則A的各項配置為：
名稱：PC-lint A(project check)
Command: D:\pclint\LINT-NT.EXE
Arguments: +ffn -i"D:\pclint" pclint_A.lnt env-vc6.lnt $(WkspName).lnt >>"D:\pclint_output\pclint_A.lnt"
Initial Directory: $(WkspDir)
其中，名稱可以根據個人習慣及實際需要進行選取，“Command”項是“LINT-NT.EXE”的全路徑，“Arguments”中涉及到A規則的lnt檔案和檢查結果的存放路徑(見2.3節)。
要注意的是，在圖5中，如果不勾選“Use Output Window”項，那麼檢查的結果會直接出現在VC++工程的輸出框中。為了儲存檢查結果，建議勾選該項(勾選後結果會儲存在2.3節所建的檔案夾下)。
配置完成之後，單擊圖5中右下角的“Close”，然後選擇VC++菜單欄上的“Tools”項，會看到Pclint規則A檢查項的名稱，如圖6所示：
圖6 Pclint規則A檢查項示意圖
3.2 Pclint規則B的配置
對于Pclint規則B的配置，操作1和操作2與規則A完全相同，操作3的各項配置如圖7所示：
圖7 Pclint規則B的配置操作3
Pclint規則B的各項配置為：
名稱：PC-lint B(project check)
Arguments: +ffn -i"D:\pclint" pclint_B.lnt env-vc6.lnt $(WkspName).lnt >>"D:\pclint_output\pclint_B.lnt"
要注意勾選“Use Output Window”項，配置完成之後，單擊圖7中右下角的“Close”，然後選擇VC++菜單欄上的“Tools”項，會看到Pclint規則B檢查項的名稱，如圖8所示：
圖8 Pclint規則B檢查項示意圖
經過以上配置之後，每次隻要單擊圖6和圖8中Pclint規則A和規則B的名稱，我們就可以用Pclint來檢查代碼了。
4. 常見的pclint規則A錯誤及修改辦法
4.1 外部聲明的函數無傳回值
錯誤提示：error 808: (Info -- No explicit type given symbol 'XXX', int assumed)。
表現形式：代碼中，在定義XXX變量的時候沒有定義其類型。
修改辦法：在XXX變量之前，添加其傳回值類型。
4.2 傳遞給函數的整型值參數超出了範圍
錯誤提示：error 419: (Warning -- Apparent data overrun for function 'strcpy(char *, const char *)', argument 2 (size=17) exceeds argument 1 (size=16)。
表現形式：代碼中，在資料移動的時候出現了資料溢出。
修改辦法：調整相關存儲結構的長度，避免資料溢出。
備注：主要指memcpy、strcpy、fgets等資料移動或轉換函數中的參數之間有隐含語義關系的函數。
4.3 定義的局部變量在該函數中未使用
錯誤提示：error 529: (Warning -- Symbol 'XXX' (line xxx) not subsequently referenced)。
表現形式：代碼中，XXX變量(位于xxx行)雖然定義了，但在後續語句中并沒有用到。
修改辦法：直接将該變量注釋掉。
備注：該類錯誤在代碼中比較常見。
4.4 布爾類型恒為真或恒為假
錯誤提示：error 774: (Info -- Boolean within 'if' always evaluates to True。
表現形式：代碼中，if語句恒為真。
修改辦法：不用if判斷，直接執行内部的函數語句。
4.5 非負數類型的變量不可能小于0，而代碼中做了小于0的判斷
錯誤提示：error 775: (Info -- non-negative quantity cannot be less than zero)。
表現形式：代碼中，某變量值(如用strlen()指派的變量)為非負數，但做了小于0的判斷。
修改辦法：将“<=0”改為“==0”。
4.6 在關系表達式中，有符号數和無符号數混合使用
錯誤提示：error 574: (Warning -- Signed-unsigned mix with relational)。
表現形式：代碼中，兩個進行比較的整型變量，一個為有符号型，另一個為無符号型。
修改辦法：在不影響功能和結果的情況下，修改其中一個變量的類型，讓兩變量的類型一緻。
4.7 對局部變量指派了，但沒有任何地方通路到該變量
錯誤提示：error 550: (Warning -- Symbol 'XXX' (line xxx) not accessed)。
表現形式：代碼中，變量XXX已經被指派，但并沒有被使用到。
修改辦法：可直接将該變量注釋掉。
4.8 函數沒有聲明，但在該函數的實作語句之前被其它函數調用了
錯誤提示：error 1055: (Error -- Symbol 'XXX' undeclared, assumed to return int)。
表現形式：代碼中，函數XXX沒有在頭檔案(.h檔案)或實作檔案(.c檔案)中聲明，并且在該函數的實作語句之前，其它函數調用了它。
修改辦法：在頭檔案中聲明該函數，或在實作檔案的前面聲明該函數。
5. 總結
本文按照操作順序介紹了如何在VC++內建開發環境中配置Linux下的Pclint工程，并詳細介紹了用pclint工具對代碼進行檢查時，規則A所包含的常見錯誤以及修改辦法，供大家參考。
“工欲善其事，必先利其器”，Pclint工具能夠發現編譯器所不能發現的問題。如果我們能夠合理地利用它，必将在一定程度上提高代碼的品質。
當然，“打鐵還需自身硬”，要想寫出高品質的代碼，光靠工具是遠遠不夠的。我們需要不斷學習、不斷提高自己編碼的水準，并用心寫好每一段代碼。