cppcheckを使用したソースコードの分析

C ++コードの静的分析に関する 最近の多く の 記事を踏まえて、ユーザーはcppcheckアナライザーに繰り返し興味を持っています。 これは比較的新しいオープンソースの静的解析プロジェクトであり、主にコード内の実際のエラーを最小限の誤検知で見つけることに焦点を当てています。

最近では、cppcheckがXorgプロジェクトの脆弱性の発見に役立ちました 。Xorgプロジェクトは23年近く存在していました。 彼はすでに世界中の何千人ものプログラマーを支援してきました。公式ウェブサイトでは、プログラムでcppcheckを使用して発見された脆弱性に関する情報を見つけることができ、このリストは常に増え続けています。 したがって、常にどこでもcppcheck を使用する必要がある理由を知りたい場合は、catを要求します。

Cppcatおよびcppcheck

このリクエストはコメントで繰り返し表明されているため、これらのユーティリティを比較することから始めます。 CppCat開発者はすでにそのような比較を行っています（PVS-Studioを使用）が、それ以来大量の水が流れ、PVS-Studio（「PVSの価格を取得するために私たちに書いてください-スタジオ。興味深いライセンスタイプを指定してください。））シングルプログラマ向けではありません。 cppcheckと同様に、CppCat は誰でもアクセスできます （特定のバージョンをVisualStudioにバインドするための予約と1年間のライセンスが必要です）。

これらのアナライザーの比較は簡単ではありません。Linux用のVisual Studioのバージョンは手元にありません。 したがって、まず、最近のCppCatレビューで既に分析されたコードの分析に限定します 。cppcheckをNotepad ++に設定し、既に準備されたCppCat分析と比較できるエラー/警告の統計を提供します。

並行して、仮想マシンにCppCatをインストールしようとしています。 Visual Studio 2010がインストールされた後、インストーラーは次のことを二度と考えずに生成したと言わなければなりません：



そのため、find-install-Visual-Studio-2013-reinstall-IE-11-reboot-updateクエストによってテストが複雑になり、アップデートの負担のない仮想マシンで正確に半日かかりました。

結果は何ですか？ Notepad ++プロジェクトを開くと、Visual Studioがフリーズします。 新しいプロジェクトを作成しようとすると、CppCat分析でヘッダーファイルが見つからないというエラーが発生しました。 したがって、前の記事で説明した内容と比較する必要があります。 Visual Studioをほぼ初めて使用しましたが、使いやすさの効果は明ら​​かです。

準備する

cppcheckはオープンソースプロジェクトであるため、誰もgitaから最新バージョンをダウンロードして自分でコンパイルする必要はありません。 Cppcheckは開発者を対象としているため、ソースコードからプログラムをコンパイルしても問題は発生しません。

unzip cppcheck-master.zip cd cppcheck-master make 

できた 具体的には、gitaから最新バージョンを取り出して別のフォルダーに入れました。将来的にはcppcheckを大幅に改善およびカスタマイズできるため、作業が簡単になります。

テスト構成：RHEL 6.1、i5-2400 @ 3.10GHzプロセッサー（アナライザーランタイムの評価用）。

アクションのための便利さはコマンドラインで行われます-必要に応じて、それらを繰り返すことができます（Linuxでは:)。 もちろん、cppcheckには一般的なIDE用のプラグインがいくつかありますが、今日ではそうではありません。

メモ帳++分析

cppcheckは、すべてのアラートがカテゴリに分類されるように設計されています。 デフォルトでは、1つのタイプの分析のみが有効になっています-エラー。 エラーは無視できません。cppcheckがエラーを返した場合、99％のケースでこの場所を書き換える必要があるためです。 cppcheckの主な問題は、メモリリークとバッファオーバーフローです。これはすでに価値があります。

合理的な疑問が生じる場合があります-notepad ++がWInAPIのみを使用する場合、Linuxオペレーティングシステムでnotepad ++を分析する方法は？ 答えは簡単です。私のメモリ内のcppcheckは、ビルド環境またはオペレーティングシステムに関連付けられていない唯一のアナライザーです。 独自のレキシカルアナライザーを使用し、すべてのヘッダーファイルの存在を必要とせず、クラスなどの複雑さに忠実です。このすばらしいプロパティにより、cppcheckをどこでも使用できます。 。

Cppcheck分析は不名誉に簡単です：

 ./cppcheck-master/cppcheck -q -j4 npp.6.5.3.src/ 

最も単純な分析はそのまま使用できます。 このコマンドは、2つのパラメーター-q（「サイレント」モード-画面に進行状況を表示しない）と-j4-プロセッサーコアの数による4スレッドのマルチスレッド分析を定義します。

前のコマンドの結果：

 [npp.6.5.3.src/PowerEditor/src/tools/ChangeIcon/ChangeIcon.cpp:214]: (error) Mismatching allocation and deallocation: resData [npp.6.5.3.src/PowerEditor/src/tools/ChangeIcon/ChangeIcon.cpp:216]: (error) Mismatching allocation and deallocation: resData [npp.6.5.3.src/scintilla/lexers/LexBash.cxx] -> [npp.6.5.3.src/scintilla/lexers/LexBash.cxx:194]: (error) Internal error. Token::Match called with varid 0. Please report this to Cppcheck developers 

稼働時間-5分。 エラー「（error）Internal error。Token :: Match called with varid0。これをCppcheck開発者に報告してください」というエラーがすぐに目に入ります。 これは、分析されたプログラムのバグの代わりに、アナライザー自体にバグがあったことを意味します:)プロジェクトがWin用に調整されており、cppcheckはDWORD、LPTRなどの意味を疑っていません。 。

実際には、たった1つのミス（2行の違い）がありました。 悪くはありませんが、おそらくメモ帳++の作成者はcppcheck自体を使用しています。 cppcheckを不審にしたコードの一部：

  BYTE* resData = new BYTE[cbRes]; LPBYTE writePtr = resData; ... if(!UpdateResource(hUpdate, RT_GROUP_ICON, lpResName, resLangId, resData, cbRes)) { _tprintf(_T("Unable to update icon group\n")); delete resData; return false; } IFDEBUG( _tprintf(_T("Updated group %d (lang %d)\n"), lpResName, resLangId); ) delete resData; } 

率直に言って、ソースは衝撃的ですが、偽陽性のように見えます。 UPD：これは未定義の動作であり、delete []演算子を使用して配列を解放する必要があります。

しかし、それだけではありません。 実際、cppcheckのモットーは誤検知がないことです。つまり、デフォルトでは、スキャナーは非常に重大なエラー（バッファーオーバーフロー、メモリリーク）のみを検索します。 すべてのエラーが見つかったら、警告フラグを有効にして再スキャンできます。

 ./cppcheck-master/cppcheck -q -j4 --enable=performance,portability,warning,style npp.6.5.3.src/ 2> npp.out 

--enableパラメーターが使用され、これにはチェックのカテゴリーが含まれます。

-パフォーマンス-パフォーマンスの問題。
-移植性-互換性の問題。
-警告-警告-不審なプログラムの場所。
-スタイル-プログラミングスタイルエラー。

このモードでは、文体的/論理的エラーと潜在的なバグ（つまり、cppcheckが「不明」であるエラー）の大部分がキャッチされます。 スキャン時間-5分。 結果をすぐにファイルに送信して、統計を収集しました。

合計メッセージ：

 wc -l < npp.out 379 

見つかったエラーのタイプに関する小さな統計：

 tr '()' '*' < npp.out | cut -d* -f2 | sort | uniq -c 3 error 39 performance 14 portability 211 style 112 warning 

合計28の一意のメッセージ。

「変数％{VAR}のスコープを縮小できます」、「Cスタイルポインターキャスト」、「変数％{VAR}はコンストラクター本体で割り当てられます。」古いプロに書かれた。

変数の海はコンストラクターで初期化されません（ 警告 ）メンバー変数％{VAR}はコンストラクターで初期化されません。 このエラーcppcheckは警告を考慮します。 nppは何らかの奇跡によって機能するため、おそらくそのようなコードの動作はコンパイラに依存します。



（ スタイル ） '||'の両側で同じ式。 同じ条件の検証。 CppCatによって同じエラーが生成されましたが、その記事ではnppバージョンが古いか、エラーが既に修正されていますが、同じコードは次のようになります。

 while (closeFound.success && (styleAt == SCE_H_DOUBLESTRING || styleAt == SCE_H_SINGLESTRING) && searchStartPoint <= caret); 

そして、これは新しいcppcheckキャッチです：

 if (!(!commentLineSybol || !commentLineSybol[0] || commentLineSybol == NULL)) 

（ パフォーマンス ）変数 'lineIndent'には、古い値が使用される前に値が再割り当てされます。 本質的に、二重の割り当て。 これは通常、コピーと貼り付けの結果ですが、cppckeckはこのようなエラーをパフォーマンスエラーとして特徴付けます。 このコードはチェックする価値があります。プログラムの作者の意図がわからないためです。 コードによる変数の未使用値と同様に、このような二重の割り当てが多数あります。

  int lineIndent = lineStart; ... lineIndent = _pEditView->execute(SCI_GETLINEINDENTPOSITION, i); _pEditView->getGenericText(linebuf, linebufferSize, lineIndent, lineEnd); 

通常、この警告は役に立ちません。コードの特定のセクションにエラーがある場合、リファクタリング中に古い値を削除するのを忘れたということはまれです。

（ 移植性 ）追加の修飾 'FunctionListPanel ::'は不要であり、多くのコンパイラーによってエラーと見なされます。 物理的に利用できず、CppCatで計画されていない有用な警告：異なるプラットフォーム間の移植性エラー（移植性）。 このコードは、すべてのコンパイラで機能するわけではありません。

 virtual BOOL CALLBACK FunctionListPanel::run_dlgProc(UINT message, WPARAM wParam, LPARAM lParam); 

この「政治的に正しい」メッセージは、実際には、gccコンパイラで松葉杖なしではコードを構築できないことを意味します。 アプリケーションを複数のプラットフォームで実行する予定がある場合、cppcheckは非常に役立ちます。

（ スタイル ）例外は参照によってキャッチする必要があります。 興味深い警告は、値ではなく参照で例外をキャッチすることです。

  catch(std::exception e) { ::MessageBoxA(NULL, e.what(), "Exception", MB_OK); return -1; } 

（ スタイル ）連続するreturn、break、continue、goto、またはthrowステートメントは不要です。 デッドコード：リターン後ブレーク：

  switch(lpnm->wID) { case REBAR_BAR_TOOLBAR: { ... return TRUE; break; } } 

（ 警告 ）関数パラメーターの割り当ては、関数の外部には影響しません。 通常、これはタイプミスを知らせる便利な警告です。関数内で割り当てられた値はどこにも送信されません。 ただし、値はクラス変数であるため、これは明らかに誤検知です。

 void SetValue( const TCHAR* _value ) { value = _value; } 

（ 移植性 ）一部のバージョンのlibcでは、フィールド幅制限のないscanfが巨大な入力データでクラッシュする可能性があります。 scanfを使用するこの習慣は、危険なバッファオーバーフローを引き起こす可能性があります。 数値変数の場合、これは簡単な未定義の動作です。

 if ( sscanf( value.c_str(), "%d", ival ) == 1 ) 

数値を変換するには、安全なstrtolを使用することをお勧めします。

別の代表者：

 sscanf( wordBuffer, "%[^.<>|&=\\/]", sKeywordBuffer ); 

wordBufferとsKeywordBufferが同じサイズであるという理由だけで、バッファーオーバーフローはありません。

（ スタイル ）「TiXmlStringA :: operator =」は「TiXmlStringA＆」を返す必要があります。 =演算子はvoidを返します。

 void operator = (const TiXmlStringA & copy); 

この演算子では、標準のC ++チェーンを使用できません。

 a = b = c; 

（ 警告 ）クラス「ControlsTab」は、親クラス「TabBar」でも定義されている「_isVertical」という名前のメンバー変数を定義します。 クラス内の変数の二重定義のエラー：

 class ControlsTab : public TabBar { public : ... private : ... bool _isVertical; }; 

親クラスですでに定義されています：

 class TabBar : public Window { ... protected: ... bool _isVertical; }; 

プロの専門家ではないので、これが可能かどうか（保護された/プライベート）すぐに答えることはできません。

（ スタイル ） 'if'と 'else'の重複ブランチが見つかりました。 CppCatでも同様のエラーが見つかりました。 追加条件：

  if(eol_mode == SC_EOL_CRLF) extraEOLLength = 2; else if(eol_mode == SC_EOL_LF) extraEOLLength = 1; else // SC_EOL_CR extraEOLLength = 1; 

（ スタイル ）符号なし変数 'lenFile'がゼロより小さいかどうかを確認します。 同様のメッセージがCppCatによって発行されましたが、windows.hファイルを検出せずにcppcheckがWPARAMなどの型を仮定しなかったことを除きます。 Windows専用の方向性がないという欠点がまだあります。

  size_t lenFile = 0; ... if (lenFile <= 0) break; 

Windowsヘッダーファイルがある場合、-Iオプションを使用してそれらへのパスを指定できると、さらに多くのエラーが発生します。

（ スタイル ）制限チェックの前に配列インデックス 'j'が使用されます。 警告の優先度は低いにもかかわらず、見つかったエラーは配列の境界を超える危険性があります。

  int j; int ReturnValue; j=startcol; if(direction == 1){j++;} if(direction != 1){j--;} while((BGHS[SI].columnwidths[j] == 0)&&(j<=BGHS[SI].cols)&&(j>0)) 

startcolパラメーターが外部である場合、-1インデックスはもちろんのこと、配列の境界から飛び出すことができます。

（ スタイル ）符号なし変数 'i'を負にすることはできないため、テストする必要はありません。 ループ内の条件は常に正==無限ループです。

 for(unsigned int i = position_of_click; i >= 0; --i) 

このエラーは、gccコンパイラと-Wall -Wextraフラグを使用してプロジェクトをビルドするときに回避できました。 このエラーは、プロジェクトを別のコンパイラエラー（タイプの不一致）にリファクタリングするときによく表示されると思います。 それはintでした-それは符号なしになりました、ここに結果があります。

軽微な欠陥

（ スタイル ）未使用の変数：ent。 この警告はコンパイラでも発行できますが、興味深いことはありません。

（ 警告 ）フォーマット文字列（2番）の％dには「int」が必要ですが、引数の型は「DWORD {aka unsigned long}」です-非常に一般的なエラーで、printfのプログラマーは変数の型と一致しない型を記述します。 これは、ほとんどのコンパイラでも起動されます。

コンストラクターのないクラス：

  class CachedValue { generic_string fullname; int index; }; 

（ パフォーマンス ）関数パラメーター 'range'は参照渡しする必要があります。 cppcheckは、引数をコピーしないように、参照によってパラメーターを渡すことをお勧めします。

 XYScrollPosition XYScrollToMakeVisible(const SelectionRange range, const XYScrollOptions options); 

（ 警告 ）関数 'empty（）'の無効な呼び出し。 代わりに「clear（）」を呼び出すつもりでしたか？ emptyメソッドは条件内でのみ意味があり、行をクリアしません。 これは誤検知であり、cppcheckは作成者が独自のStringクラスを作成することを疑いませんでした:)メソッドの命名ロジックを確認する必要があります。

（ スタイル ） 'class ByteArray'には、クラスに割り当てられたメモリへのポインタが含まれるため、推奨されるコピーコンストラクタがありません。 cppcheckは、プログラマが実装を忘れた場合に備えて、クラスに欠落しているコピーコンストラクタを作成することを推奨しています。

おわりに

どちらのアナライザーもかなりの量のエラーを検出し、それらの多くは各アナライザーに固有のものです。 一般に、オープンでクロスプラットフォームであり、バグを見つけてプログラミングスタイルの改善に役立つため、常にcppcheckを手元に置いておくとよいでしょう。 通常、cppcheckを使用しても問題はありません。

この分析から、ツールは互いに補完し合うと結論付けることができます。 一部の人にとって、cppcheckの主な欠点はVisual Studioのプラグインがないことです。そのため、cppcheckの作成者はPVS-Studioを試してみることをお勧めします。 コマンドラインインターフェイスにもかかわらず、cppcheckの使用は非常に便利です。 コンパイラもIDEもヘッダーファイルも必要ありません。これは、これまで見た中で最も使いやすい静的アナライザーです。 さらに、仮想マシンにWindows用のcppcheckアセンブリを特別にインストールしました-素晴らしいグラフィカルインターフェイスがあり、迅速にインストールして、問題なく分析を実行します。



分析結果をXMLにエクスポートして、ブラウザーで表示できます。

両方のプロジェクトで開発の成功を願うべきです-これらは本当に非常に必要なプログラムです。 そして、今すぐcppcheck開発に参加できます。プロジェクトをチェックし、見つかったエラーまたは見つからないエラーについてcppcheck開発者に書き込み、バグを報告し、有用なパッチをgithubに送信します。 最近までcppcheckがif（malloc（））エラーを見つけることができなかった場合、メモリリークに関するメッセージを注いでいるだけです-競合の結果は明らかです。

cppcheckでヘッダーファイルを探す場所を明示的に指定すると、この分析は大幅に改善される可能性があります。関数はメモリを割り当てたり解放したりします。 記事が大きくなったため、特定のプロジェクト用にcppcheckを構成し、分析の品質を向上させ、cppcheckのルールを独自に作成する方法（次回）。

PSナンセンスを許してください。 Cppcheckの設定には、Windows専用のコードを分析する機能があります。そのため、多くの興味深いエラーが見逃されていました。 フラグ--platform = win32Aを使用してnppを分析する必要がありました。