Clangを使用したPVS-Studioの検証

はい、はい。 あなたは正しく聞いた。 今回の記事は「その逆」です。 プロジェクトをチェックするのではなく、別のツールを使用してアナライザーをチェックします。 実際、これは以前に行ったことがあります。 たとえば、Cppcheckを使用してPVS-Studioをチェックし、Visual Studioに組み込まれたアナライザーを使用して、Intel C ++の警告を調べました。 しかし、記事を書く理由はありませんでした。 面白いものは見つかりませんでした。 しかし、Clangは診断メッセージに関心を寄せることができました。



PVS-Studio [ 1、2 ]を使用してClangを 2回テストし、毎回興味深いものを見つけました。 しかし、PVS-Studioを検証することはできませんでした。 Clang開発者は、Visual C ++を使用して開発されたWindowsプロジェクトの構築が得意であることを長い間報告してきました。 しかし実際には、どういうわけかうまくいきません。 または、私たちは幸運ではありません。



そして先日、突然Clangを使用してアナライザーを簡単にテストできることに気付きました。 反対側からタスクにアプローチする必要がありました。 毎晩、GCCを使用してLinux用PVS-Studioのコマンドラインバージョンを取得します。 また、GCCコンパイラは非常に簡単にClangに置き換えられます。 したがって、PVS-Studioを簡単に確認できます。 そして本当に。 同じ日に、従業員の1人に明るいアイデアが浮かんだので、PVS-Studioの検証に関するレポートがありました。 今、私は座ってレポートの内容と私の印象について話します。

HTMLレポートの印象

もちろん、私はすでにClangを扱っています。 ただし、サードパーティのプロジェクトの分析の質を判断することは困難です。 間違いがあるかどうか分からないことがよくあります。 ソースコードで37ポイントのパスを表示する必要があることをClangが示している場合は特に怖いです。



それどころか、PVS-Studioのコードは私には馴染みがあり、ついにClangが発行したレポートを完全に操作することができました。 残念ながら、これは、検出されたエラーを達成するためにしばしば示される方法は冗長であり、プログラマを混乱させるという私の以前の印象を確認しました。 プログラムの実行に重要なポイントを与え、そのようなパスを構築することは非常に難しいタスクであることを理解しています。 たとえば、PVS-Studioの場合、一般にこのような膨大なタスクを引き受けることを恐れています。 ただし、Clangはこのパスのデモンストレーションを実装しているため、明らかにこのメカニズムをさらに改善する必要があります。



さもなければ、そのようなポイントはただノックダウンし、結論を散らかし、理解を複雑にします：

図は「ポイントN4」を示しています。 以下はエラーです。 条件が満たされない場合にのみエラーが発生することを理解しています。 これはClangが報告するものです。 しかし、なぜこの情報を表示するのでしょうか？ そのため、条件が真の場合、関数は終了し、エラーは発生しません。 余分な無意味な情報。 そのような冗長な情報はたくさんあります。 明らかに、このメカニズムは改善可能であり、改善すべきです。



しかし、私はClang開発者の功績を称えたいと思います。 多くの場合、このようなパスを表示すると、特に複数の機能が関与している場合に、エラーの原因を理解するのに役立ちます。 また、Clang開発者は、明確に、Visual Studio 2013静的アナライザーよりもはるかに優れたエラーを達成する方法を示しました。 そして、この着色が与えるものは完全に理解不能です。

見つかったエラーの重大度

PVS-Studioの確認は非常に良い例であり、十分にテストされた作業中のプロジェクトでの静的解析の利点を示すための感謝のないタスクです。 実際、次のように言って、すべての間違いから「逃げる」ことができます。

• このコードは現在使用されていません。
• このコードはごくまれに使用されるか、エラー処理に使用されます。
• このエラーは、顕著な結果にはつながりません（その修正は、多数のリグレッションテストでは決して現れません）。

otmazyvatsyaを持っているので、私は深刻な間違いを犯していないように見えます。誇らしげに見えると、Clangはプログラミングの初心者にのみ適していると言えます。



もちろん、私はそうは言いません！ 重大なエラーが見つからなかったという事実は、Clangが分析に弱いという意味ではありません。 このような欠陥がないことは、さまざまな方法によるテストに関する多くの作業の結果です。

• 内部ユニットテスト。
• 診断回帰テスト（マークアップされたファイル）;
• さまざまなC ++コンストラクトとさまざまな拡張子を含む* .iファイルのセットのテスト。
• 90のオープンソースプロジェクトでの回帰テスト。
• そして、もちろん、PVS-Studioを使用した静的分析。

このような徹底的な防御の後、Clangがヌルポインターの20の逆参照と0による10の除算を見つけることは期待しにくいです。しかし、考えてみてください。 慎重にテストされたプロジェクトでさえ、Clangはいくつかのバグを発見しました。 これは、定期的に使用すれば、多くのトラブルを回避できることを意味します。 * .iユーザーからPVS-Studioがクラッシュするファイルを取得するよりも、Clangが検出したときにエラーを修正することをお勧めします。



当然、私たちは自分自身で結論を出しました。 今、私の同僚は、サーバー上でClangの起動を設定し、アナライザーが何かを見つけた場合にログをメールに送信するだけです。

誤検知について

合計で、Clangアナライザーは45個の警告を生成しました。 誤検知の数について話したくありません。 12箇所を修正する必要があります。



実際、「誤検知」は相対的な問題です。 正式には、アナライザーは正しいです-コードは不正で疑わしいです。 しかし、これは欠陥が見つかったという意味ではありません。 例で説明します。



最初に、実際の誤検知を検討します。

#define CreateBitMask(bitNum) ((v_uint64)(1) << bitNum) unsigned GetBitCountForRepresntValueLoopMethod( v_int64 value, unsigned maxBitsCount) { if (value == 0) return 0; if (value < 0) return maxBitsCount; v_uint64 uvalue = value; unsigned n = 0; int bit; for (bit = maxBitsCount - 1; bit >= 0; --bit) { if ((uvalue & CreateBitMask(bit)) != 0) // Clang: Within the expansion of the macro 'CreateBitMask': // The result of the '<<' expression is undefined { n = bit + 1; break; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私が理解しているように、アナライザーは、シフト操作が未定義の動作につながる可能性があると報告しています。 どうやら、Clangはロジックで混乱したか、変数maxBitsCountの可能な値の範囲を正しく計算できませんでした。 GetBitCountForRepresntValueLoopMethod（）関数がどのように呼び出されるかを注意深く研究しましたが、「maxBitsCount」変数の値が大きすぎる状況を見つけることができませんでした。 シフトを理解しています[ 3 ]。 だから、エラーはないと確信しています。



自信はありますが、十分ではありません。 したがって、私はここにそのようなアサート（）を入力しました：

 .... for (bit = maxBitsCount - 1; bit >= 0; --bit) { VivaAssert(bit >= 0 && bit < 64); if ((uvalue & CreateBitMask(bit)) != 0) ....
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのテストで、このassert（）は機能しませんでした。 したがって、これは実際にClangアナライザーの誤検知の例です。



assert（）を追加することの良い結果は、Clangがレポートを停止したことです。 assert（）マクロに焦点を当てています。 アナライザーに変数値の可能な範囲を伝えます。



このような真の誤検知はほとんどありません。 これらのメッセージの多くがあります：

 static bool G807_IsException1(const Ptree *p) { .... if (kind == ntArrayExpr) { p = First(p); kind = p->What(); // Clang: Value stored to 'kind' is never read ....
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

割り当て「kind = p-> What（）;」は使用されません。 以前はそうでしたが、変更後、この行は不要になりました。 アナライザーは正しいです。 この行は不要です。このコードに同行する人を混乱させないように、少なくとも削除する必要があります。



別の例：

 template<> template<> void object::test<11>() { .... //  nullWalker     . VivaCore::VivaWalker *nullWalker = 0; left.m_simpleType = ST_INT; left.SetCountOfUsedBits(32); left.m_creationHistory = TYPE_FROM_VALUE; right.m_simpleType = ST_INT; right.SetCountOfUsedBits(11); right.m_creationHistory = TYPE_FROM_EXPRESSION; result &= ApplyRuleN1(*nullWalker, left, right, false); // Clang: Forming reference to null pointer .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単体テストでは、nullポインターが逆参照されます。 はい、これはできませんし、canいです。 しかし、本当にしたい。 実際、VivaWalkerクラスのインスタンスを準備することは非常に難しく、この場合、オブジェクトへの参照はまったく使用されません。



両方の例は、機能するコードを示しています。 ただし、これを誤検知とは呼びません。 これらは対処する必要がある欠陥です。 ただし、これらの警告は「found errors」列にも記載しません。 だからこそ、誤検知は相対的な概念だと言います。

見つかったバグ

最後に、ClangがPVS-Studio内で見つけた興味深いコードスニペットを表示するセクションに行きました。



発見されたエラーはプログラムにとって重要ではありません。 言い訳をしようとはしていません。 しかし、それは本当にそうでした。 すべての警告を編集した後、回帰テストではPVS-Studioの動作の違いは明らかになりませんでした。



しかし、私たちは本当の間違いについて話しているので、Clangがそれらを見つけることができたことは素晴らしいことです。 定期的なリリースにより、新しいPVS-Studioコードのより深刻な間違いを見つけることができるようになりました。

2つの初期化されていない変数を使用する

コードは大きく複雑でした。 記事に入れることは意味がありません。 エラーの本質を反映した合成コードを作成しました。

 int A, B; bool getA, getB; Get(A, getA, B, getB); int TmpA = A; // Clang: Assigned value is garbage or undefined int TmpB = B; // Clang: Assigned value is garbage or undefined if (getA) Use(TmpA); if (getB) Use(TmpB);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Get（）関数は、変数AおよびBを初期化できます。変数AおよびBを初期化するかどうかにかかわらず、変数のgetA、getBに注意します。



変数AとBが初期化されているかどうかにかかわらず、それらの値はTmpA、TmpBにコピーされます。 この時点で、初期化されていない変数が使用されています。



これが重大ではないエラーだと言っているのはなぜですか？ 実際には、タイプ 'int'の初期化されていない変数をコピーしても問題はありません。 正式には、私が理解しているように、未定義の動作が発生します。 実際には、ゴミは単純にコピーされます。 ガベージを含むその他の変数は使用されません。



コードは次のように書き直されました。

 if (getA) { int TmpA = A; Use(TmpA); } if (getB) { int TmpB = B; Use(TmpB); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化されていないポインター

GetPtreePos（）関数の呼び出しを見てみましょう。 初期化されていないポインターへの参照を渡します。

 SourceLocation Parser::GetLocation(const Ptree* ptree) { const char *begin, *end; GetPtreePos(ptree, begin, end); return GetSourceLocation(*this, begin); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは間違っています。 GetPtreePos（）関数は、ポインターがnullptrに初期化されることを前提としています。 仕組みは次のとおりです。

 void GetPtreePos(const Ptree *p, const char *&begin, const char *&end) { while (p != nullptr) { if (p->IsLeaf()) { const char *pos = p->GetLeafPosition(); if (....) { if (begin == nullptr) { // Clang: The left operand of '==' is a garbage value begin = pos; } else { begin = min(begin, pos); } end = max(end, pos); } return; } GetPtreePos(p->Car(), begin, end); p = p->Cdr(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単体テストサブシステムで特定のコード解析エラーが発生したときにGetLocation（）関数が呼び出されるのは残念なことです。 どうやら、これは起こったことがない。



静的分析がTDDを補完する方法の良い例です[4]。

怖い明示的なキャスト

型変換が怖くて正しくない3つの類似した関数があります。 それらの1つを次に示します。

 bool Environment::LookupType( CPointerDuplacateGuard &envGuard, const char* name, size_t len, Bind*& t, const Environment **ppRetEnv, bool includeFunctions) const { VivaAssert(m_isValidEnvironment); //todo: Environment *eTmp = const_cast<Environment *>(this); Environment **ppRetEnvTmp = const_cast<Environment **>(ppRetEnv); bool r = eTmp->LookupType(envGuard, name, len, t, ppRetEnvTmp, includeFunctions); ppRetEnv = const_cast<const Environment **>(ppRetEnvTmp); // Clang: Value stored to 'ppRetEnv' is never read return r; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソドムとゴモラ。 不変性を取り除こうとしました。 そして、受け取った値を返します。 しかし、実際には、「ppRetEnv = const_cast ....」という行では、ローカル変数ppRetEnvが単に変更されています。



そのような不名誉がどこから来たのか、それがプログラムにどのように影響するのかを説明しましょう。



PVS-Studioアナライザーは、OpenC ++ライブラリに基づいています。 実際には、キーワード「const」は使用しませんでした。 いつでも、非定数オブジェクトへのポインターを使用して、何でもどこでも変更できます。 PVS-Studioはこの欠陥を継承しました。



彼らは彼と戦った。 しかし、まだ最後までではありません。 constを1か所に記述し、2番目に記述し、次に3番目に記述する必要があります。 次に、特定の状況では、ポインターを使用して何かを変更する必要があり、関数を部分に分割するか、さらに広範なリファクタリングを実行する必要があることがわかりました。



理想主義的な協力者の一人をどこでもconstにしようとする最後の英雄的な試みは1週間かかり、部分的に失敗しました。 コードとデータストレージ構造の編集に大きな変更が必要であることが明らかになりました。 闇の王国への光の持ち込みは停止されました。 検討されているように、スタブのいくつかの機能があり、その目的はコンパイルされたコードを作成することです。



このエラーは何に影響しますか？ 奇妙なことに、それは何であろうと思われます。 すべての単体テストと回帰テストでは、修正後のPVS-Studioの動作の変化は明らかになりませんでした。 どうやら、「ppRetEnv」の戻り値は職場ではあまり必要ではないようです。

潜在的に初期化されていない変数を使用する

 v_uint64 v; // Clang: 'v' declared without an initial value verify(GetEscape(p, len - 3, v, notation, &p)); retValue <<= 8; retValue |= v; // Clang: Assigned value is garbage or undefined
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GetEscape（）関数は正常に動作しない場合があり、変数「v」は初期化されないままになります。 何らかの理由でGetEscape（）の結果がverify（）マクロをチェックします。 どのように起こったのかはすでにわかっていません。



エラーは次の理由で気付かれません。 GetEscape（）関数は、PVS-Studioアナライザーが誤ったプログラムテキストで動作する場合にのみ変数を初期化しません。 正しいプログラムテキストでは、正しいESCシーケンスが常に存在し、変数は常に初期化されます。

自分自身がどのように機能したかを驚かせた

 Ptree *varDecl = bind->GetDecl(); if (varDecl != nullptr) { if (varDecl->m_wiseType.IsIntegerVirtualValue()) varRanges.push_back(....); else if (varDecl->m_wiseType.IsPointerVirtualValue()) varRanges.push_back(....); else varRanges.push_back(nullptr); } rangeTypes.push_back(varDecl->m_wiseType.m_simpleType); // Clang: Dereference of null pointer
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

varDeclポインターはnullptrの場合があります。 ただし、最後の行は常に実行されます。 また、nullポインター逆参照が発生する場合があります：varDecl-> m_wiseType.m_simpleType。



ここに一度も転落したことがないのは、私には謎です。 唯一の仮定は、オブジェクトが変数宣言（変数の宣言子）へのポインターを格納していない場合、ここに到達しないことです。 しかし、とにかくそれに頼ることはできません。



非常に重大な間違いが見つかりましたが、今ではそうでなければ、いつの日か確かにそれが証明されます。

驚くべきことに、ここでも滝は見られませんでした。

別の素晴らしい場所。 どうやら、nullポインターの逆参照につながる可能性のある要因の組み合わせはほとんどありません。 少なくとも、この関数の記述以来、落下は認識されていません。 しかし、その後、一年半が経過しました。 奇跡

 void ApplyRuleG_657(VivaWalker &walker, const BindFunctionName *bind, const IntegerVirtualValueArray *pReturnIntegerVirtualValues, const PointerVirtualValueArray *pReturnPointerVirtualValues, const Ptree *body, const Ptree *bodySrc, const Environment *env) { if (body == nullptr || bodySrc == nullptr) { VivaAssert(false); return; } if (bind == nullptr) return; if (pReturnIntegerVirtualValues == nullptr && pReturnPointerVirtualValues == nullptr) return; .... size_t integerValueCount = pReturnIntegerVirtualValues->size(); // Clang: Called C++ object pointer is null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポインターpReturnIntegerVirtualValuesはnullptrである可能性があります。



一見、エラーは状態にあり、「||」演算子を使用する必要があるようです。

 if (pReturnIntegerVirtualValues == nullptr && pReturnPointerVirtualValues == nullptr)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これはそうではありません。 状態は正しいです。 ポインターを間接参照する前に、ポインターがnullでないことを確認する必要があります。 ゼロの場合、integerValueCount変数は0に設定する必要があります。正しいオプション：

 size_t integerValueCount = pReturnIntegerVirtualValues != nullptr ? pReturnIntegerVirtualValues->size() : 0;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すごい 非常に多くのテスト。 90のオープンソースプロジェクトで実行されます。 さらに、今年は他の多くのプロジェクトをチェックしました。 それでも、コードにはバグが存在します。 そして、彼は私たちの重要な潜在的なクライアントで自分自身を見せていただろう。



静的アナライザーに栄光を！ Clangに栄光を！

その他

アナライザーは、修正する必要のあるエラーをさらに明らかにしました。 それらを記述することは困難ですが、私は合成例を作りたくありません。 さらに、いくつかの警告がありますが、これらは完全に真実ですが、役に立たないものです。 そこで、分析をオフにする必要がありました。



たとえば、ClangはRunPVSBatchFileMode（）関数を使用するときに初期化されていない変数が心配でした。 しかし、実際には、バッチ起動は単にLinuxに実装されておらず、スタブがあります。 また、まだ実装する予定はありません。

結論

作業中に静的アナライザーを使用します。



PVS-Studioコアは高度にテストされています。 ただし、Clang静的アナライザーは12の実際のエラーを検出しました。 他の場所はエラーではありませんが、臭いがするコードであり、私はそのような場所をすべて修正しました。



見つかったエラーは、最も不適切な瞬間であることが判明する可能性があります。 さらに、このアナライザーは、テストで捕捉された多くのエラーを見つけるのに役立つと思います。 メインの回帰テストの実行には約2時間かかります。 もっと早く何かを見つけたら、それでいい。



Clang広告を含む記事を次に示します。 しかし、彼はそれに値しました。



他のアナライザーはほとんど役に立たないとは思わないでください。 たとえば、個人的にはCppcheckアナライザーが本当に好きです。 非常に使いやすく、非常に明確な診断機能を備えています。 しかし、たまたま彼がPVS-Studioで多数のエラーを見つけられなかったため、彼に関する同様の記事を書くことはできません。



そして、もちろん、仕事でPVS-Studioアナライザーを使用することをお勧めします。 Visual C ++ [ 5 ]を使用している人にとって非常に便利です。 特に、変更されたファイルのコンパイルが成功した後に開始される自動分析について忘れないでください。

この記事は英語です。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 ClangでPVS-Studioを確認します。

追加のリンク：

1. アンドレイ・カルポフ。 PVS-Studio対Clang
2. アンドレイ・カルポフ。 静的解析は定期的に適用する必要があります 。
3. アンドレイ・カルポフ。 フォードを知らない、水に入ってはいけない。 パート3（シフト操作について） 。
4. アンドレイ・カルポフ。 静的分析がTDDを補完する方法 。
5. アンドレイ・カルポフ。 PVS-Studio for Visual C ++ 。