今天終於把pclint環境搭建好了，可以在windows直接使用sis寫代碼並用pclint檢查代碼了。下面介紹下： <轉載自: hi.baidu.com/qiupingwu>1. PC-Lint 是什麼?
如果你真的不知道它是什麼? 那麼請私下詢問 Google, 但千萬不要聲張:-).
簡單而言, PC-Lint 是 Gimpel Software 公司出品的一個很牛<注1>的軟體, 你可以叫它吹毛求疵器, 因為它能夠做比編譯器嚴格得多的(包括但不限於)語法檢查. 事實上這個工具有兩個版本: 一個叫 PC-Lint, 是針對 PC 機的 (主要是對付 Windows, MS-DOS, OS/2 等系統), 以可執行檔形式發布; 另一個叫 FlexeLint, 是針對其它系統的 (比如 Linux), 採用源碼方式發布. 由於很少見到 FlexeLint, 本文僅就 PC-Lint 的使用進行介紹. 目前在官方網上出現的最新版本是 9.0, 但同樣不易獲得, 所以本文只介紹 PC-Lint8.0. 我們將採用變通的方法實現對 Linux 系統下的代碼檢查. 2. 使用環境
正如前面所說, PC-Lint 本來只當遊弋於 Windows, OS/2 之上, 但由於 C 的標準化做得比較好, 所以稍作變通, PC-Lint 是完全有能力對付那些針對 Linux 系統的代碼的.
除了作業系統環境, 要想使用得順手, 還應該把 PC-Lint 和編譯/編輯環境結合起來. 現在 PC-Lint 已經能很好地和大部分主流編譯/編輯器整合, 使用起來非常方便. 下文將就這兩個方面進行討論. 2.1. 配合 Linux 的使用
在 Linux 系統下, 通常使用 GCC 作為 C 代碼的編譯器. 為了使 PC-Lint 能有效地檢查針對 Linux 的代碼, 應該為它選定正確的頭 (.h) 檔案. 通常這些檔案都放在 /usr/include 和 /usr/<x.y.z>/include 目錄下.
由於 PC-Lint 不能在 Linux 系統上運行, 所以要把上面兩個目錄映射 (作磁碟映射) 到 Windows 系統, 這樣目錄就變成了 Z<注3>:/usr/include 和 Z:/usr/<x.y.z>/include. 也可以把 Linux 的標頭檔直接 COPY 到 Windows 系統中, 這時系統會提示檔案重名, 但這些檔案一般用不到, 直接覆蓋就行.
（我是直接拷貝到windows下c:/pclint/usr下，不過沒有拷貝/usr/<x.y.z>/include）
為了讓 PC-Lint 能認出這兩個目錄, 要在 std.lnt 檔案中增加
-iZ:/usr/include
-iZ:/usr/3.4.3/include
兩行.
另外由於 PC-Lint 是針對 Windows 設計的, 會抱怨 Linux 某些標頭檔不正確. 由於我們不提倡自己修改標準檔案, 因此乾脆讓 PC-Lint 暫時失聲好了. 這可以通過在 options.lnt 檔案增加下面幾行實現:
-e716 // allow use while (1)
// bug in syslog.h, it define __need_va_list_ macro
-efile(537,stdarg.h)
-emacro(530,va_start) // do not init first parameter
修改 options.lnt 檔案, 使用 gnu 檢查規則, 即應該有如下一行:
c:/pclint/lnt/co-gnu3.lnt
假設 PC-Lint 安裝在 C:/pclint 目錄下.
配置好這些, 在 Windows 上檢查 Linux 代碼就應該比較順手了. 2.2. 配合 SourceInsight 的使用
在 SourceInsight 中可以建立一個命令. 通過 Custom Commands 視窗, 在其中的 Command 中填入命令名 (比如是 lint), 再在 Run 中 填入
C:/pclint/LINT-NT.EXE -u -ic:/pclint/lnt std.lnt env-si %f
再在 Pattern 框裡填寫
^/(.*/.[a-zA-Z]+/)/w/([0-9]+/).*
然後點擊 Add 按鈕即可.
此後要對 C 檔案進行檢查時, 直接執行該命令即可. 3. 配置
上面的配置都是一成不變的, 配置好之後, 基本上都不需要改動了. 但對於不同的項目, 還有一些針對項目本身的特殊配置. 在這一小節, 將對針對特定項目的配置進行說明. 首先, 每個項目都有各自的標頭檔, 因此需要在 std.lnt 指定項目的標頭檔目錄. 格式如下:
-i<標頭檔目錄>
例如:
-iZ:/sw-new/src/license
另外, 如果項目有些目錄是第三方提供的, 或者我們不關注其中的警告, 則可以把這些目錄指定為庫目錄. 格式如下:
+libdir(<庫目錄1>,<庫目錄2>,...)
例如:
+libdir(z:/usr/include,z:/usr/3.4.3/include,z:/mysql/include)
對於以前沒檢查過的項目, 第一次使用 PC-Lint 檢查時, 可能會出現很多警告和錯誤. 為了不至於使有用的錯誤掩埋於警告之中, 可以在 options.lnt 中配置全域的檢查等級, 使其只顯示嚴重的錯誤. 方法為:
-w<等級數>
其中等級數越大, 輸入的警告錯誤就越多. 建議逐漸加大此數, 分步消除錯誤和警告. 比如先從
-w1
開始.
還可以使用
-e<錯誤號碼>
暫時屏蔽對某個錯誤的檢查. 4. 避免無病呻吟
也會有這樣的情況: 對某些代碼, 你確認----想想你的論據是否充分, 別急於下此結論哦:-)----沒有問題, 但 PC-Lint 卻在每次檢查時都抱怨, 這時可以通過在代碼作特殊注釋讓 PC-Lint 跳過某些檢查.
PC-Lint 提供了大量的特殊注釋, 可以把這些注釋加到代碼中, 對代碼的每個段落、每一行甚至每個運算式進
行精細的檢查控制. 下面列舉出一些常用的選項, 更多選項可參數 PC-Lint 的使用手冊. 注意這些選項都要放到 C 代碼的注釋中, 且格式為 /*lint <xxxx> */, 其中 lint 必須緊接在 /* 後面出現, <xxxx> 表示選項, 選項後留一個空格, 然後才是 */.
1). -e(#[,#]...) 僅對下一個運算式有效,
a = /*lint -e(413) */ *(char *)0;
與
a = /*lint -save -e413 */ *(char *)0
/*lint -restore */;
是等價的.
2). --e(#[,#]...) 對其所在的整個運算式有效,
a = /*lint --e(413) */ *(int *)0 + *(char *)0;
將阻止兩個 413 資訊的輸出, 而使用 -e(413) 則只阻止第一個 413 輸出. 3). -e{#[,#]...} 對下一個語句或者聲明有效. 這種用法的影響範圍很靈活: 當其在函數之前時, 對整個函數有效; 在某個指派陳述式前, 對該個指派陳述式有效; 在 if 或 while 等語句前對這整個語句段有效. 4). --e{#[,#]...} 對於其所處的 {} 號內的整個代碼體有效, 這包括函數體, 類, 結構等等. 如果不處於任何 {} 號內, 則對整個檔案有效 (當然, 是指從 --e{} 出現的地方至檔案結束). 5). !e# 僅對其所在行有效.
6). -esym(#,sym[,sym]) 對指定的符號屏蔽警告. 5. 常見錯誤處理
下面列舉一些常見的錯誤, 及處理方法, 供參考:
525 提示錯誤縮排, 原因是代碼中空格和 TAB 鍵混合使用了, PC-Lint 認為代碼的縮排與代碼邏輯不符合. 把代碼統一改成使用空格即可<注5>. 715 符號未被引用, 原因是在函數中的某個調用參數或者局部變數沒被使用. 對局部變數可以直接去掉, 對於參數則把其放到 if 語句中即可.
740 提示不尋常的類型轉換, 通常發生在指標類型轉換時, 轉換前後指標所指類型空間大小不一致時. 可通過在轉換前加
/*lint -e(740) */
的方式屏蔽此警告. 818 函數的指標參數在函數內部沒被修改, 提示參數定義為常量指標. 按照提示在指標參數前加上 const 修飾符就可以了. 但是似乎 PC-Lint 在處理這個問題的時候有 BUG, 有時即使加了 const 修飾符還是會繼續提示此警告, 此時就應該在對這個函數這個指標參數屏蔽 818 警告, 方法為在函數開始前添加
/*lint -esym(818, pointer) */
在函數結束後添加
/*lint +esym(818, pointer) */
827 不可到達的代碼, 原因是在 while (1)/for (;;) 後還有代碼, 但這些代碼永遠無法執行到. 解決方案是在不能執行到的程式碼前加上
/*lint -unreachable */
<1> 並非因為是在牛年出品, 而是因為它確實本來就很牛.
<2> 這裡是指當前使用的 GCC 版本, 比如 3.4.3.
<3> 假設映射到 Z 盤.
<4> 原因是 Linux 檔案名稱區分大小寫, 而 Windows 不區分.
<5> 這種工作可以由 indent 代勞, 相信它, 它能做得很好. |
