一、引言

靜態(tài)代碼分析是指無需運(yùn)行被測代碼，通過詞法分析、語法分析、控制流、數(shù)據(jù)流分析等技術(shù)對程序代碼進(jìn)行掃描，找出代碼隱藏的錯(cuò)誤和缺陷，如參數(shù)不匹配，有歧義的嵌套語句，錯(cuò)誤的遞歸，非法計(jì)算，可能出現(xiàn)的空指針引用等等。統(tǒng)計(jì)證明，在整個(gè)軟件開發(fā)生命周期中，30%至70%的代碼邏輯設(shè)計(jì)和編碼缺陷是可以通過靜態(tài)代碼分析來發(fā)現(xiàn)和修復(fù)的。

在C++項(xiàng)目開發(fā)過程中，因?yàn)槠錇榫幾g執(zhí)行語言，語言規(guī)則要求較高，開發(fā)團(tuán)隊(duì)往往要花費(fèi)大量的時(shí)間和精力發(fā)現(xiàn)并修改代碼缺陷。所以C++靜態(tài)代碼分析工具能夠幫助開發(fā)人員快速、有效的定位代碼缺陷并及時(shí)糾正這些問題，從而極大地提高軟件可靠性并節(jié)省開發(fā)成本。

靜態(tài)代碼分析工具的優(yōu)勢：

1. 自動執(zhí)行靜態(tài)代碼分析，快速定位代碼隱藏錯(cuò)誤和缺陷。
2. 幫助代碼設(shè)計(jì)人員更專注于分析和解決代碼設(shè)計(jì)缺陷。
3. 減少在代碼人工檢查上花費(fèi)的時(shí)間，提高軟件可靠性并節(jié)省開發(fā)成本。

二、業(yè)界主流靜態(tài)代碼掃描工具概況

目前市場上的C++靜態(tài)代碼分析工具種類繁多且各有千秋，本文將分別介紹TSC團(tuán)隊(duì)自主研發(fā)的tscancode工具和當(dāng)前4種主流C++靜態(tài)代碼分析工具(cppcheck、coverity、clang、pclint)，并從功能、效率、易用性等方面對它們進(jìn)行分析和比較，以期幫助C++開發(fā)人員更清晰靜態(tài)代碼分析工具的工作效果、適用場景和擴(kuò)展空間，同時(shí)在其對應(yīng)項(xiàng)目特征中選擇合適的工具應(yīng)用到項(xiàng)目開發(fā)環(huán)節(jié)中。

以下為工具在付費(fèi)價(jià)格、規(guī)則數(shù)量、準(zhǔn)確率、掃描效率、編譯依賴、IDE支持、跨平臺支持、可擴(kuò)展開發(fā)方面的對比數(shù)據(jù)。注：本次競品分析的選擇了3款游戲項(xiàng)目（約500萬行代碼）。

在可擴(kuò)展性上，TSC有專人維護(hù)，定期根據(jù)用戶需求擴(kuò)展規(guī)則或新增功能特性，cppcheck和clang是開源工具，工具更新較慢，但如果用戶有特殊需求可以自己擴(kuò)展開發(fā)，pclint和coverity是商業(yè)軟件，難以進(jìn)行功能擴(kuò)展。

同時(shí)，TSC有完整代碼質(zhì)量管理閉環(huán)平臺QOC支持；coverity和clang可用web端的結(jié)果展示，但無法自行管理問題流，需要進(jìn)行二次開發(fā)；cppcheck和pclint缺少web端結(jié)果展示。

以下重點(diǎn)比較具體檢查規(guī)則和有效問題報(bào)錯(cuò)率。

三、檢查規(guī)則大比拼

1.規(guī)則大類

針對業(yè)內(nèi)大量掃描工具在實(shí)際項(xiàng)目中掃描結(jié)果的影響比較，我們將代碼質(zhì)量問題分為以下幾大類：

1. 致命類：可能導(dǎo)致程序宕機(jī)、無響應(yīng)等影響范圍極大的錯(cuò)誤；
2. 邏輯類：可能造成程序不能達(dá)到預(yù)期邏輯結(jié)果的錯(cuò)誤；
3. 編碼規(guī)范及其他類：可能造成程序的可讀性、可維護(hù)性較差的錯(cuò)誤（不可達(dá)代碼，無效的變量聲明等）；

2.規(guī)則大類分布

根據(jù)3大影響分類，其嚴(yán)重程度分別為高、中、低，各類型規(guī)則數(shù)量分布為：

從規(guī)則分類占比來看：

1. TSC針對互聯(lián)網(wǎng)產(chǎn)品高效開發(fā)修復(fù)原則，工具定位為針對致命和邏輯類問題，相對傳統(tǒng)、軍事、安全領(lǐng)域，并不關(guān)注編碼規(guī)范及編譯錯(cuò)誤；
2. coverity作為商業(yè)化軟件，在付費(fèi)后添加規(guī)則上，達(dá)到覆蓋率最全面，除致命和邏輯類規(guī)則外，還有大量編碼規(guī)范、安全和針對其他語言（如java，C#）的規(guī)則；
3. cppcheck作為開源工具，應(yīng)用范圍廣泛，根據(jù)開源社區(qū)場景搜集，在各方面都有規(guī)則添加，但場景較為粗獷，場景雖多，但有效率不高。例如：cppcheck在初始化檢查上有5個(gè)子規(guī)則，樣本代碼共掃描出312個(gè)問題，其中有效問題僅8個(gè)，有效率僅為3%。
4. pclint作為商業(yè)化軟件，在付費(fèi)后添加規(guī)則上，達(dá)到覆蓋率最全面，除致命和邏輯類規(guī)則外，還有大量編碼規(guī)范、安全的規(guī)則；
5. clang作為開源軟件，規(guī)則較少，但規(guī)則類型分布較為均勻，在致命、邏輯類，還有編碼規(guī)范、安全類都有規(guī)則添加。

3.規(guī)則報(bào)錯(cuò)數(shù)量

整體規(guī)則數(shù)量上：pclint[915]>coverity[515]>cppcheck[245]>clang[74]>TSC[67]

可以看出pclint和coverity規(guī)則最多，TSC和clang規(guī)則最少，原因有如下3點(diǎn)：

1. pclint和coverity作為商業(yè)化軟件，需求來源于傳統(tǒng)軟件、軍事、安全各個(gè)領(lǐng)域，其規(guī)則總數(shù)最多，其編碼規(guī)范類規(guī)則數(shù)量分別高達(dá)646條和382條；排除掉低價(jià)值的編碼規(guī)范類規(guī)則，規(guī)則數(shù)量排序?yàn)椋?br /> pclint[269]>cppcheck[151]>coverity[133]>TSC[67]>clang[44]
2. 在規(guī)則實(shí)際報(bào)錯(cuò)數(shù)量上，以3款游戲500萬行代碼的結(jié)果覆蓋度來看；
   

   注：規(guī)則總數(shù)指工具所有的規(guī)則總數(shù)，報(bào)錯(cuò)規(guī)則數(shù)指開啟工具所有規(guī)則情況下，掃描樣本代碼所覆蓋的規(guī)則數(shù)量。

   從實(shí)際項(xiàng)目掃描結(jié)果來看：

   掃描出問題的規(guī)則數(shù)/規(guī)則總數(shù)：

   TSC[60%]>cppcheck[27%]>clang[19%]>coverity[10%]>pclint[9%]

   pclint、coverity、cppcheck雖然規(guī)則數(shù)量很多，但因?yàn)槠涠ㄖ萍尤氲拇蟛糠忠?guī)則普遍適用度不高，大量規(guī)則可能在多個(gè)項(xiàng)目中都無法掃描出問題。有些規(guī)則卻在多個(gè)項(xiàng)目中掃描出大量非核心的問題，如：函數(shù)沒有被調(diào)用、未使用的變量、存在多余的頭文件等。

3. 規(guī)則數(shù)量多來源于兩個(gè)方面，一方面是規(guī)則覆蓋更全面，另一方面是規(guī)則粒度劃分得更細(xì)；

通過對具體規(guī)則進(jìn)行分析，發(fā)現(xiàn)在規(guī)則劃分粒度由細(xì)到出排序?yàn)閇pclint，coverity，cppcheck，clang，TSC]

pclint和coverity劃分粒度最細(xì)，cppcheck，clang次之，TSC最粗。

例如：coverity的除0報(bào)錯(cuò)分為整型除0，浮點(diǎn)數(shù)除0，取模除0；數(shù)組下標(biāo)越界也細(xì)分為訪問越界、讀越界、寫越界。Pclint和cppcheck初始化分為變量未初始化、結(jié)構(gòu)體成員未初始化、類成員未初始化、string未初始化、data未初始化、union未初始化、全局靜態(tài)變量未初始化等；而TSC則合并了一些過細(xì)的規(guī)則，未初始化上只分為變量未初始化和成員未初始化。

粒度劃分越細(xì)既有優(yōu)點(diǎn)也有缺點(diǎn)：

優(yōu)點(diǎn)：可以針對細(xì)分規(guī)則靈活配置開關(guān)，關(guān)掉準(zhǔn)確率低的規(guī)則

缺點(diǎn)：規(guī)則數(shù)量太多， 用戶配置相當(dāng)麻煩，新用戶很難理解多個(gè)相似的規(guī)則之前的區(qū)別。

TSC為降低用戶配置難度，在規(guī)則粒度劃分上相對粗獷，但會從中提取出其中準(zhǔn)確率低的場景，作為單獨(dú)規(guī)則，從而達(dá)到可以關(guān)掉低準(zhǔn)確率規(guī)則的目的。

四、同類規(guī)則效果對比分析

本文針對每個(gè)工具在關(guān)鍵報(bào)錯(cuò)項(xiàng)，如：空指針、越界、變量未初始化、內(nèi)存泄露、邏輯上的報(bào)錯(cuò)結(jié)果進(jìn)行分析。

樣本代碼——3款游戲項(xiàng)目（約500萬行代碼）代碼

測試對象——tscancode2.0、coverity7.5、cppcheck1.68、pclint9.0、clang3.4

有效報(bào)錯(cuò)數(shù)——某類規(guī)則在3款游戲項(xiàng)目的有效報(bào)錯(cuò)數(shù)總和

準(zhǔn)確率——某類規(guī)則在3款游戲項(xiàng)目的平均準(zhǔn)確率，準(zhǔn)確率=有效報(bào)錯(cuò)數(shù)/報(bào)錯(cuò)總數(shù)*100%

綜合評分——綜合有效報(bào)錯(cuò)數(shù)和準(zhǔn)確率的評分，有效報(bào)錯(cuò)數(shù)和準(zhǔn)確率的權(quán)值暫定為45：55，綜合評分=有效報(bào)錯(cuò)/最大有效報(bào)錯(cuò)數(shù)*100*45%+準(zhǔn)確率*100*55%

1.空指針規(guī)則

空指針檢查規(guī)則主要檢查是否存在對賦值為空的指針解引用的情況，空指針是c/c++中最大的問題，經(jīng)常造成程序崩潰的致命錯(cuò)誤。因此，C++靜態(tài)代碼分析工具對空指針的檢查能力顯得尤為重要。

圖為五個(gè)工具對樣本代碼掃描結(jié)果：

有效報(bào)錯(cuò)數(shù)：TSC [401] >coverity[219]>>clang[57] >cppcheck[20]>pclint[14]

準(zhǔn)確率：coverity[95%]≈TSC[92%] ≈clang[90%]>>cppcheck[28%]>pclint[14%]

綜合評分：TSC[96分] >coverity[77分] >clang[56分]>cppcheck[18分]>pclint[8分]

1. 從準(zhǔn)確率來看，在空指針檢查方面，不考慮掃描效率和掃描環(huán)境搭建復(fù)雜度，TSC、coverity和clang都很優(yōu)秀，三者準(zhǔn)確率都很高。cppcheck， pclint在結(jié)果準(zhǔn)確率上和數(shù)量上都較差，不推薦使用。
2. 從空指針規(guī)則細(xì)分程度來看，TSC和coverity相當(dāng)，細(xì)分場景挖掘更多，cppcheck規(guī)則并未細(xì)分空指針規(guī)則，從實(shí)際項(xiàng)目結(jié)果來看，只能檢查出dereferenceBeforeCheck場景的錯(cuò)誤。Clang和pclint在空指針細(xì)分上維度跟TSC和coverity不同，比如：它們區(qū)分是參數(shù)指針解引用還是局部變量解引用，細(xì)分粒度不夠且覆蓋場景較少，其覆蓋場景基本都被TSC和coverity包含。
   

   cppcheck掃描出來的問題存在大量誤報(bào)，誤報(bào)主要是冗余的判空，并不會引起實(shí)際問題，具體誤報(bào)場景如下：

   
3. 從有效報(bào)錯(cuò)數(shù)量上，TSC有效報(bào)錯(cuò)數(shù)量更多，細(xì)分場景挖掘更多，無疑是掃描 空指針最佳選擇；clang覆蓋的場景較少，其有效報(bào)錯(cuò)基本都能被coverity和TSC覆 蓋，不過由于其準(zhǔn)確率較高且免費(fèi)，與TSC搭配使用也是不錯(cuò)的選擇；而coverity雖然覆蓋場景多但因?yàn)橹粫?bào)完全可信的問題，因此會漏掉部分有效報(bào)錯(cuò)，例如：指針變量 來源于函數(shù)返回值，而函數(shù)返回值是否為NULL依賴于用戶輸入，在靜態(tài)分析中 coverity無法判斷其是否會為NULL，為保證準(zhǔn)確率會漏掉該指針報(bào)錯(cuò)。若項(xiàng)目對空指 針漏報(bào)容忍度較高，且有足夠預(yù)算采購商業(yè)軟件，可以選擇coverity；而cppcheck和 pclint檢查出的有效問題極少并伴隨大量誤報(bào)，同上結(jié)論，不宜使用。
4. 在易用性上，coverity和clang編譯環(huán)境構(gòu)建復(fù)雜，編譯時(shí)長增加較多；TSC在易用性上也有一個(gè)缺點(diǎn)，即為提高準(zhǔn)確率，在個(gè)別項(xiàng)目存在一次性配置工作。原因是個(gè)別項(xiàng)目存在自定義判空宏，但由于不依賴編譯，TSC掃描的代碼可能并不完整，導(dǎo)致個(gè)別自定義判空宏找不到，需要在cfg.ini中配置自定義判空宏。當(dāng)然，如果掃描的代碼完整度同編譯環(huán)境，則無此問題。

2.越界規(guī)則

越界一般來講是指數(shù)組下標(biāo)越界，或者緩沖區(qū)讀寫越界。這類錯(cuò)誤會導(dǎo)致非法內(nèi)存的訪問，引發(fā)程序崩潰或者錯(cuò)誤。

下圖是五個(gè)工具對樣本代碼掃描結(jié)果：

注：越界對誤報(bào)判定的規(guī)則比較嚴(yán)格，即使場景識別本身無誤，但是通過代碼邏輯可以推斷該場景不會越界的也判定為誤報(bào)。

例如：

這里由found變量間接推斷出data[region_index]不會越界，將其判定為誤報(bào)。

從報(bào)錯(cuò)數(shù)量和準(zhǔn)確率來看：

有效報(bào)錯(cuò)數(shù)：coverity[98]>>TSC [18]>pclint[16] >cppcheck[6]> clang[4]

準(zhǔn)確率：clang[100%] >coverity[80%]>TSC[70%] >cppcheck[67%]>>pclint[2%]

綜合評分：coverity[90分] >TSC[54分]≈clang[55分]>cppcheck[40分]>pclint[1分]

1. 在報(bào)錯(cuò)數(shù)量上，coverity在越界檢查上有較大的優(yōu)勢，因?yàn)閏overity有較強(qiáng)的符 號查找和場景識別能力，能識別相對復(fù)雜的越界場景。其他四個(gè)工具同coverity相比還 有差距，其中pclint存在大量誤報(bào)，表現(xiàn)最差。如：TSC和cppcheck只能識別數(shù)組變量 本身越界，但如果是一個(gè)指針p指向數(shù)組的第一個(gè)元素，通過p[i]訪問時(shí)的越界，TSC 和cppcheck都無法檢查，而coverity能找到p所指向的數(shù)組定義，得到數(shù)組大小，從而 判斷p[i]是否越界。
2. clang越界這塊的準(zhǔn)確率雖然最高為100%，但其覆蓋的場景單一（strncpy使用越界報(bào)了4條），其報(bào)錯(cuò)都被TSC和coverity覆蓋，數(shù)量上和其他工具有較大差距。TSC越界檢查結(jié)果要略好于cppcheck，clang和pclint，TSC增加了對變量取值范圍的推斷，檢測出是否存在越界的風(fēng)險(xiǎn)。比如：
   
   
   （TSC越界有效報(bào)錯(cuò)場景）

對于數(shù)組下標(biāo)iCountry的判定存在風(fēng)險(xiǎn)，代碼執(zhí)行到當(dāng)前上下文時(shí)，iCountry可能 取值為MAX_QT_COUNTRY_JIFEN_ITEM_CNT，而這正是數(shù)組m_astDataInDB的長 度，也就是說在這種邊界情況下會造成了數(shù)組訪問越界。對于如上場景，應(yīng)該將代碼修 改為iCountry>= MAX_QT_COUNTRY_JIFEN_ITEM_CNT。

3.變量未初始化規(guī)則

變量未初始化顧名思義：變量聲明后沒有賦初值，其分配的內(nèi)存值是隨機(jī)的。這也是代碼中容易出現(xiàn)的問題，會導(dǎo)致不確定的程序行為，造成嚴(yán)重的后果。

下圖是五個(gè)工具對樣本代碼掃描結(jié)果：

注：結(jié)果排除了3個(gè)工具都有的檢查項(xiàng)——構(gòu)造函數(shù)中是否存在未初始化成員變量。在實(shí)際項(xiàng)目中發(fā)現(xiàn)，C++類構(gòu)造函數(shù)中對成員變量不做初始化的情況是普遍的，很多代碼會采用“延遲初始化”，即在實(shí)際用到該對象的時(shí)候調(diào)用類似Initialize的方法進(jìn)行初始化。因此在此次對比中并沒有把這條規(guī)則納入進(jìn)來。

從報(bào)錯(cuò)數(shù)量和準(zhǔn)確率來看：

有效報(bào)錯(cuò)數(shù)：coverity[75]>>pclint[25] >TSC [9]>cppcheck[8]> clang[1]

準(zhǔn)確率：TSC[75%] >coverity[68%]>pclint[26%] > clang[17%] >cppcheck[3%]

綜合評分：coverity[82分] > TSC[47分] >pclint[30分] > clang[10分] >cppcheck[6分]

1. 在報(bào)錯(cuò)數(shù)量上，coverity初始化檢查場景覆蓋比其他四個(gè)工具要全，TSC為保持 準(zhǔn)確率，規(guī)則覆蓋上比較保守，而cppcheck存在比較嚴(yán)重的誤報(bào)問題，準(zhǔn)確率僅為 3%。pclint的誤報(bào)也相對很高，clang在初始化這塊顯得無能為力。從上圖可以很容易發(fā) 現(xiàn)cppcheck的誤報(bào)數(shù)量相當(dāng)?shù)酶?，cppcheck會將如下的場景判定為未初始化：
   
   （cppcheck誤報(bào)場景）

   SMD_POS是一個(gè)簡單的結(jié)構(gòu)體，它包含了一個(gè)空的構(gòu)造函數(shù)，cppcheck依據(jù)這點(diǎn) 判定這是一個(gè)未初始化的錯(cuò)誤。但這樣的場景不會有什么問題，算是一個(gè)誤報(bào)。這導(dǎo)致 了cppcheck在未初始化規(guī)則的結(jié)果可信度大大降低。

2. coverity在未初始化這塊的場景覆蓋比較全，特別是對結(jié)構(gòu)體對象的字段的初始 化情況的檢測，因?yàn)槠浠诰幾g可對變量做路徑跟蹤，例如：構(gòu)造函數(shù)里面調(diào)用了init() 函數(shù)，coverity會繼續(xù)跟蹤init()函數(shù)中是否有對變量的賦值，所以掃描覆蓋場景最全。 coverity的誤報(bào)主要分為兩類：一類是對幾種未初始化場景的識別上存在問題，如：，變 量在某個(gè)分支的確沒有初始化，但用了一個(gè)狀態(tài)標(biāo)識其未初始化，當(dāng)使用這個(gè)變量前會 使用狀態(tài)標(biāo)記來判斷其是否沒有初始化，保證使用的變量都是初始化過了的。另一類就 是上面提到的“低價(jià)值報(bào)錯(cuò)”，即通過代碼邏輯或者做了代碼保護(hù)，保證變量不會因?yàn)?沒有初始化而產(chǎn)生實(shí)際的問題。如：一個(gè)表示時(shí)間的結(jié)構(gòu)體，里面字段有year， month，day，hour，min，day這個(gè)字段沒有初始化，但實(shí)際代碼中也沒有用到這個(gè)字段，因此并不會產(chǎn)生任何問題。

   TSC在未初始化變量的檢查因不具備路徑分析能力，而以分支作用域檢查特定變量 在各個(gè)代碼分支的初始化情況，誤報(bào)率保持在相對低的一個(gè)水平。但場景覆蓋較少，沒 有針對結(jié)構(gòu)體字段的初始化場景做覆蓋。因?yàn)閷Y(jié)構(gòu)字段的初始化方式相對比較多樣： 逐個(gè)字段初始化，函數(shù)調(diào)用初始化，構(gòu)造函數(shù)初始化等。

4.內(nèi)存/資源泄露規(guī)則

內(nèi)存泄漏指由于疏忽或錯(cuò)誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存，從而造成了內(nèi) 存浪費(fèi)的情況。內(nèi)存泄漏是靜態(tài)下很難檢測的一種錯(cuò)誤，一般需要?jiǎng)討B(tài)分析工具進(jìn)行檢 測，如valgrind工具會捕獲malloc()/free()/new/delete的調(diào)用，監(jiān)控內(nèi)存分配和釋放，從 動態(tài)上檢測程序是否存在內(nèi)存泄漏。因此，靜態(tài)代碼分析能檢查的內(nèi)存泄漏就非常有限 了，當(dāng)前各工具主要是從代碼寫法上檢查內(nèi)存分配和釋放是否配對使用。比如：fopen 打開文件后在退出函數(shù)前是否有執(zhí)行fclose，new[]和delete[]是否配對使用等。

下圖是五個(gè)工具對樣本代碼掃描結(jié)果：

注：以上數(shù)據(jù)排除了cppcheck35個(gè)低價(jià)值報(bào)錯(cuò)，這里排除的cppcheck35個(gè)報(bào)錯(cuò)都是基本數(shù)據(jù)類型的new和delete不匹配（如char* p=new char[100];delete p;）雖然這種寫法不規(guī)范，但由于實(shí)際上不會造成內(nèi)存泄漏，很多項(xiàng)目不會對此進(jìn)行修復(fù)。

從報(bào)錯(cuò)數(shù)量和準(zhǔn)確率來看：

有效報(bào)錯(cuò)數(shù)：pclint[55] >TSC[40]>coverity [29]>cppcheck[28]> clang[0]

準(zhǔn)確率：coverity[100%]=cppcheck[100%] >TSC[73%]>pclint[23%] > clang[N/A]

綜合評分：coverity[79分] ≈ TSC [73分]≈cppcheck[77分]>pclint[57分]>clang[0分]

從報(bào)錯(cuò)數(shù)量上看出，在內(nèi)存泄漏檢查方面，pclint雖然發(fā)現(xiàn)有效問題最多，但誤報(bào)很高，不推薦使用。TSC的有效錯(cuò)誤數(shù)比coverity和cppcheck多，但誤報(bào)也相對較高。clang則不具備泄露類場景的檢測能力。

注：由于靜態(tài)掃描能檢查的內(nèi)存泄露場景都非常明確，因此一般都不會出現(xiàn)問題，TSC的15個(gè)誤報(bào)也非場景識別有誤而是工具底層bug導(dǎo)致，后續(xù)會對底層bug進(jìn)行修復(fù)。如：#ifdef 和#else分支中各有一個(gè)fopen，實(shí)際編譯時(shí)只會走其中1個(gè)分支識別1次fopen，但由于底層bug識別了2次fopen，導(dǎo)致誤報(bào)。

5.邏輯錯(cuò)誤規(guī)則

邏輯錯(cuò)誤:指可能存在的邏輯問題，如if不同分支內(nèi)容相同，在switch內(nèi)缺少break等，對指針使用sizeof進(jìn)行空間分配等問題。

下圖是五個(gè)工具對樣本代碼掃描結(jié)果：

注：這些報(bào)錯(cuò)中剔除了一些無修改意義且結(jié)果數(shù)量很多規(guī)則:如:coverity掃描存在7484條Logically dead code(邏輯代碼不可達(dá))報(bào)錯(cuò)。cppcheck存在2246條unusedFunction(函數(shù)未被使用)報(bào)錯(cuò)。

從報(bào)錯(cuò)數(shù)量和準(zhǔn)確率來看：

有效數(shù)量：TSC[293]>coverity[164]>clang[142] >cppcheck [120]>pclint[116]

準(zhǔn)確率：clang[97%] >TSC[93%]>coverity(88%)>pclint[72%] >cppcheck[55%]

綜合評分：coverity[94分] > TSC[86分] > clang[80分] >cppcheck[63分] >pclint[27分]

從報(bào)錯(cuò)數(shù)量和準(zhǔn)確率上可以看出TSC可以更有效的發(fā)現(xiàn)邏輯類問題。但各工具邏輯類場景各有特色，互為互補(bǔ)，可以一同選擇掃描，但cppcheck和pclint準(zhǔn)確率較低，可以較少選擇。clang的準(zhǔn)確率最高，但clang掃描出來的邏輯錯(cuò)誤中有一大半為低價(jià)值的邏輯錯(cuò)誤，比如clang掃描出來的142條邏輯錯(cuò)誤中就有140條“變量賦值但沒有使用”錯(cuò)誤。

①TSC，coverity具備較強(qiáng)宏展開能力

以DuplicateExpression規(guī)則為例，TSC發(fā)現(xiàn)DuplicateExpression規(guī)則報(bào)錯(cuò)32條，cppcheck發(fā)現(xiàn)DuplicateExpression規(guī)則報(bào)錯(cuò)12條。因?yàn)門SC可以對宏進(jìn)行更有效展開，例如：

這種報(bào)錯(cuò)TSC可以準(zhǔn)確的識別出來，宏MAX_TASK_TAB_SIZE和MAX_TASK_RES_NUM為相同的數(shù)值，而cppcheck無法區(qū)分發(fā)現(xiàn)這類問題，只能進(jìn)行簡單的文本匹配。coverity在推斷能力上也不差，在這點(diǎn)也明顯優(yōu)于cppcheck。

②TSC規(guī)則類型更有效

經(jīng)過篩選，TSC只保留價(jià)值更高的推斷和有效規(guī)則；

Ø增加一些函數(shù)檢查規(guī)則，如：MemsetZeroBytes，這種錯(cuò)誤的Memset寫法：memset(ctYear， sizeof(ctYear)，0)；可疑的數(shù)組下標(biāo)使用等這些規(guī)則在coverity邏輯類檢查中并沒有體現(xiàn)，而coverity只會報(bào)出非常準(zhǔn)確的報(bào)錯(cuò)如：if分支完全相同等檢查項(xiàng)。

Ø剔除價(jià)值低的無效規(guī)則，如coverity規(guī)則Logically dead code，指一些邏輯上不可達(dá)的廢棄代碼；cppcheck規(guī)則memsetClassFloatc指對存在Float類型成員變量的Class
使用Memset，當(dāng)時(shí)代碼中發(fā)現(xiàn)基本都是Memset為0，并不會有數(shù)據(jù)丟失等問題。故這類規(guī)則發(fā)現(xiàn)有效問題很低，在數(shù)量較大的情況下，需要耗費(fèi)大量的人力來確認(rèn)，性價(jià)比不高，TSC已經(jīng)將這種規(guī)則剔除。

總的來說，TSC在發(fā)現(xiàn)問題和準(zhǔn)確率方面表現(xiàn)都不錯(cuò)，可以節(jié)省大量的人力在鎖定邏輯類型錯(cuò)誤。

TSC在某些細(xì)小規(guī)則的推斷能力上比coverity要稍微弱一些，如規(guī)則Missing break in switch：coverity發(fā)現(xiàn)全部準(zhǔn)確的報(bào)錯(cuò)，TSC存在一定的誤報(bào)，這些復(fù)雜場景需要較強(qiáng)的動態(tài)計(jì)算如：

五、常見誤報(bào)場景

1.空指針常見誤報(bào)場景

誤報(bào)場景一（cppcheck）

以上538行代碼報(bào)quiz_set_ptt存在空指針訪問。

誤報(bào)原因：538行只是指針的比較，并沒有解引用，這是一個(gè)比較低級的誤報(bào)。

誤報(bào)場景二（coverity）

以上119行代碼報(bào)actor存在空指針訪問，判定邏輯如下：112行對actor進(jìn)行了判空，說明actor在當(dāng)前上下文可能為空。所以119行actor可能為空。

誤報(bào)原因：xy_assert_retval是個(gè)宏，展開后包含有return語句，即如果actor為空115行就返回了，119行actor不會為空。

2.越界常見誤報(bào)場景

誤報(bào)場景一（TSC）

以上83行代碼報(bào)第數(shù)組訪問可能越界，判定邏輯如下：第61行的if語句對req_list.num的取值范圍作了限制，req_list.num在當(dāng)前上下文的最大值可以是
MAX_RECRUIT_REQ_LIST_SIZE(4)；83行req_list._數(shù)組對象用req_list.num作為其數(shù)組訪問的下標(biāo)，當(dāng)req_list.num取值為MAX_RECRUIT_REQ_LIST_SIZE時(shí)發(fā)生越界（req_list._數(shù)組的長度為MAX_RECRUIT_REQ_LIST_SIZE(4)）。

誤報(bào)原因：第79行的if條件保證了之后的代碼req_list.num的值不會等于MAX_RECRUIT_REQ_LIST_SIZE，所以這是一個(gè)誤報(bào)。

誤報(bào)場景二（cppcheck）

以上第691行代碼報(bào)t_index_map可能取值-1越界，判定邏輯如下：665行聲明t_index_map并賦值為-1，t_index_map的賦值在681行，但681行在for循環(huán)里面，而for循環(huán)存在不能進(jìn)入的可能性，所以在691行使用t_index_map可能未初始化。

誤報(bào)原因：進(jìn)入691行代碼的前提條件是found變量為true，而found為true保證了t_index_map被賦值了。

誤報(bào)場景三（coverity）

以上第146行代碼報(bào)src_index + 1可能取值為4越界，判定邏輯如下：139行對src_idx的取值范圍進(jìn)行了限定：[0， 3](TEAM_MEMBER_MAX長度為4)，因此146行src_idx + 1可能為4導(dǎo)致對team_ptr->team_member訪問越界。

誤報(bào)原因：144行對src_idx的取值范圍進(jìn)行了過濾，保證了src_idx+1不會越界。

3.未初始化常見誤報(bào)場景

誤報(bào)場景一（cppcheck）

以上第462行代碼報(bào)ret未初始化錯(cuò)誤，判定邏輯如下：ret變量在第434行聲明，在switch中的兩個(gè)case中均有初始化代碼，但是在default分支中沒有對ret進(jìn)行初始化，因此判定462行可能會返回一個(gè)沒有初始化的ret。

誤報(bào)原因：default分支中的xy_assert_retval是一個(gè)宏，因?yàn)閏ppcheck宏查找策略的原因?qū)е略摵隂]有展開。實(shí)際上宏展開包含了return語句，也就是說如果進(jìn)入default分支就函數(shù)就直接返回而不會執(zhí)行到462行代碼。

誤報(bào)場景二（coverity）

以上第284行代碼報(bào)careers未初始化錯(cuò)誤，判定邏輯如下：careers數(shù)組在第278行聲明，但在for循環(huán)對每個(gè)數(shù)組成員進(jìn)行了初始化。這可能造成careers完全沒有初始化，或者只初始化了一部分。因此在284行使用careers存在未初始化錯(cuò)誤。

誤報(bào)原因：通過代碼邏輯可知，career_num代表的是careers被初始化的長度，在訪問careers數(shù)組元素的時(shí)候，通過career_num進(jìn)行了保護(hù)，因此不會出現(xiàn)未初始化的錯(cuò)誤。

4.泄露類常見誤報(bào)場景

誤報(bào)場景一（TSC）

以上第63行代碼報(bào)fp存在資源泄露風(fēng)險(xiǎn)錯(cuò)誤，判定邏輯如下：xy_assert_retnone宏展開后，含有return語句，也就是說fp在調(diào)用fclose之前可能返回，存在泄露風(fēng)險(xiǎn)。

誤報(bào)原因：實(shí)際上代碼邏輯決定了函數(shù)return的前提條件fp為空。這個(gè)時(shí)候是沒有必要調(diào)用fclose的，不存在泄露風(fēng)險(xiǎn)。

誤報(bào)場景二（pclint）

以上第139行代碼(~CGIProcessor()， 析構(gòu)函數(shù))報(bào)存在資源泄露風(fēng)險(xiǎn)錯(cuò)誤，因?yàn)闆]有釋放_cgiContainer。判定邏輯如下：_cgiContainer作為CGIProcessor的一個(gè)指針成員（第149行），需要在析構(gòu)函數(shù)中進(jìn)行釋放，否則為內(nèi)存泄露。

誤報(bào)原因：CGIProcessor對象并不own _cgiContainer指向的對象，不需要它來釋放。

5.邏輯類常見誤報(bào)場景

誤報(bào)場景一（cppcheck）

以上4596行代碼報(bào)“對包含有float成員的對象調(diào)用memset方法”錯(cuò)誤。

誤報(bào)原因：利用memset對一個(gè)對象的數(shù)據(jù)字段清零是比較常見的做法，float成員清零后值也為0，不會造成什么問題。

原文轉(zhuǎn)載自：