CodeSonarとPC-lintの比較に関する真実

この記事は翻訳であり、競合製品PVS-Studioの開発者として、私自身の状況の評価を控えることに、読者の注意をすぐに向けたいと思います。



静的分析業界のリーダーおよびインスピレーションとして認知されている私たち（Gimpel Software）は、ツールの開発における品質基準として、他の企業が当社の製品に導かれていることを喜んでいます。 通常、当社のアナライザーと他の製品との比較結果に関する出版物に何らかの形で対応する必要はないと考えていますが、Grammatechがリリースし、CodeSonarとPC-lintツールを比較する「エキスパートレポート」は非常に不快な例外であることが判明しました。 このドキュメントの著者は、製品のメリットに焦点を当てる代わりに、PCリントとその技術的能力の不実表示に関する虚偽の陳述に頼りました。これはおそらく市場からの圧力の結果であり、この嘘に対応する義務があると考えています。実際の状況について話します。

PC-lintについて

PC-lintは、CおよびC ++での静的コード分析のための開発者の間で効果的で尊敬されるツールです。 1985年にGimpel Softwareによって作成され、それ以来継続的に開発されています。 この30年間、PC-lintは業界のリーダーであり、ユーザーに革新的な機能を提供しています。たとえば、機能とプログラムモジュール間を移動するときにデータを追跡するメカニズム、厳密な型チェックと次元分析、ユーザー定義の機能のサポートなどです。 PC-lintは、何万人もの開発者、技術管理の専門家、テスター、法医学の専門家から信頼されています。 多数のコンパイラとプラットフォームをサポートし、多くの追加オプションを提供します。 PC-lintは、医療や自動車産業など、安全性が要求される分野を含む、ほぼすべての業界で使用されています。

グラマテックレポートについて

「CodeSonarとPC-lint（および同様のツール）との比較方法」というタイトルの専門家レポートは、Grammatech Webサイトで入手できます。 このドキュメントは、CodeSonarとPC-lintツールを比較した結果の信頼性の高いプレゼンテーションを提供すると主張しています（他のアナライザーについても言及していますが、主な重点はPC-lintにあります）が、実際には、実際の事実によってサポートされていない自己奉仕の虚偽のステートメントにすぎません読者を誤解させるように設計されています。 これらの虚偽の主張に基づいて、レポートの著者は、PC-lintのためにCodeSonar製品を好ましい観点から提示しようとしています。

反論計画

PC-lintを中傷しようとして、ドキュメントの作成者は特定の戦術に頼ります。

• 彼らは、PC-lintの技術的手段と機能がPC-lintの存在中に実際には発展しなかったという仮定に基づいて推論を行っています。
• 彼らは意図的にPC-lintのタスクと機能を誤解しています。
• PC-lintの診断機能について虚偽の主張をする。

これらのステートメントの検討と反論は、この記事の2つのセクションに当てられます。 「Accusations」セクションでは、レポートの重要な規定を検証しますが、そのほとんどはいかなる証拠にも裏付けられておらず、事実を提供します。 「例による事実の歪み」セクションでは、著者によると、PC-lintを使用して検出できないエラーを含むレポートで使用されるコード例を検討し、これらのフラグメントの分析結果でツールの実際の診断メッセージを表示します。 このレポートには、いくつかの合理的な批判も含まれています。対応するセクションでそれらを検討します。

告発

グラマテックのレポートは、次のような、かなり曖昧で極めて不正確な一連のステートメントを提案しています。

• ソースコード内のソフトウェアエラーを検索するように設計された静的分析ツールは、数十年前から存在します。 リントファミリツールなどの第1世代のアナライザーは、現在プリミティブと見なされています。 このようなツールには、PC-lintなどの商用製品と、Cppcheckなどのオープンソースプロジェクトの両方が含まれます。 近年、それらはCodeSonarを含むより高度なツールに取って代わりました。

Unixの元の「リント」は非常に原始的なものであることに同意しますが、類似の名前に基づいてのみ同じ品質を製品に帰そうとする試みは、せいぜい不誠実に見えます。 30年以上にわたり、Gimpel Softwareは静的解析のリーダーであり、PC-lintはこの間多くの技術的進歩に貢献してきました。

• CodeSonarの主なタスクは、大規模なコードベースの重大な欠陥を検索することですが、第一世代のツールのタスクははるかに控えめです。 これらは主に、本質的でないコーディング標準のコードの矛盾を見つけ、より厳密な型制御を提供するように設計されています。

ここでは、PC-lintと同じ「第1世代のツール」を混在させようとする別の試みと、PC-lintのタスクが「はるかに控えめ」であるというstatement慢な発言が見られます。 PC-lintの主なタスクは、小規模および大規模プロジェクトの両方で、バッファオーバーフロー、境界外配列、論理エラー、未定義の動作などの「実際の」エラーを含むプログラムエラーを検索することです。 また、多くの競合他社の能力を超えるニーズを抱えるお客様の最も多様なニーズを満たすことも目指しています。 このような要求には、さまざまなMISRA標準のサポート、厳密な型制御、ユーザーセマンティクスのサポートなどが含まれます。 原則として、あらゆる種類のエラーを効果的に検出できるツールはないことを理解し、より高い目標を設定します。 PC-lintは、重大な欠陥を見つけるだけでなく、その外観につながるプログラミングテクニックを特定することも目的としています。 幅広いPCリント機能が複雑なエラーを検出できないことを意味すると考えるのは正しくありません。

• 第一世代のツールはいくつかの重大なエラーを見つけることができると主張していますが、実際には、最も些細な問題しか検出できません。

繰り返しになりますが、この声明は元のリントに関しては正しいかもしれませんが、PCリントに関してはそうではなく、そのような連続性を暗示して、レポートの著者は偽善的に振る舞い、読者を欺きます。



さらに、著者は関数間のデータ転送に関連するエラーの例をいくつか示し、PC-lintはそれらのいずれも見つけることができないと主張します（実際には、これらのエラーのほとんどすべてと、レポートに記載されていないものもあります） 、次を宣言します。

• ここで説明する例はすべて非常に単純です。 残念ながら、実際のコードははるかに複雑です。多くのコンパイル単位、抽象化レベル、およびエイリアスの使用による変数間の非常に混乱した関係を考慮する必要があります。 また、浅いレベルの分析を備えた第一世代のツールは、短い例では単純な欠陥を見つけることはできませんが、実際のアプリケーションでさまざまな重大なエラーを見つけるにはまったく不適切です。 一方、CodeSonarは、多くの高度な方法を使用してプログラムの構造をモデル化しているため、実際のエラーを見つけることができます。

このステートメントは、テスト中にPC-lintがレポートで考慮されたエラーを検出できなかったという誤った仮定から始まります。その後、著者はツールで使用されるいくつかのユニークな「トリック」をリストしますが、実際にはPC-lintは同じメカニズムを使用します。 「プリミティブアナライザーで」見つけることができないという声明に反して、CodeSonarの登場前に実装されました。



ユーザーインターフェイスについて言えば、著者は次のように述べています。

• 比較される製品のユーザーインターフェイスは大きく異なります。 PC-lintやCppcheckなどの第1世代のアナライザーは、もともとコンパイラーのようなコマンドラインから実行することを目的としていました。 したがって、分析の結果を含むレポートはテキストとして表示されます。 これらのツールをより広いユーザーインターフェイスと統合するためのソリューションはありますが、これらのソリューションは元々アナライザー用に開発され、しっかりと接続されているインターフェイスよりも効果が低くなります。 以下に例を示します。

まず、PC-lintには出力形式の非常に柔軟な設定があり、デフォルトではテキスト、HTML、およびXML形式をサポートしていることに注意してください。 グラフィカルインターフェイスに関しては、PCリントアナライザー自体と一緒に、ユーザーは既存のアプリケーションとの統合に必要なツールも受け取ります。 そのため、多くの一般的な開発環境の構成を提供しています。 さらに、Visual StudioやEclipseなどの開発環境と統合するための真剣で完全なソリューションを開発しているサードパーティ組織がいくつかあります。



レポートは次の結論で終わります。

• PC-lintやCppcheckなどの第1世代の静的アナライザーで使用されている技術は、過去30年間あまり変わっていません。 このため、彼らは深刻なソフトウェアエラーを見つけることができません。 これらのツールを使い続ける開発者は、数十年にわたる静的解析の開発の利点を奪っています。

報告書のほぼ残りの部分のように、引用された一節の3つの声明のいずれにも真実の粒が含まれていません。 これは、以前の故意に誤った論文に基づいた絶対的なフィクションです。

例による事実のゆがみ

ご注意

レポートに示されている例は不完全なことが多く、これはおそらくデモンストレーションの性質によるものであるため、製品の客観的な比較やGrammartechの声明の確認を許可していません。 このため、レポートの作成者は、使用するほとんどの例を「微調整」して、完全な自己完結型のコードフラグメントのように見せかけました（たとえば、デモページOnline Demoのように ）。 これを行うには、関数内にコードブロックを配置し、最初は未定義の型と関数を宣言し、タイプミスを修正します。 いずれの場合でも、これらの変更はコードのセマンティクスや目的のエラーを検出するPC-lintの機能には影響しませんが、他のツールで同じ結果を再現するタスクを促進するだけです。

バッファオーバーフロー（静的）

void test_buffer_overrun(int p[]) { p[4] = 1729; } void test_driver(void) { int test[4]; test_buffer_overrun(test); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフラグメントに関連して、レポートには次のことが記載されています。



PC-lintは、プロシージャの境界を通過するデータのパスを追跡できないため、このエラーを診断できません。



これは最も一般的な嘘です。 機能間を移動するときにデータを追跡するメカニズムは、15年前にPC-lintで実装されましたが、レポート内でのその存在は否定されています。 ユーザーがプロジェクトのニーズと利用可能なハードウェアリソースのバランスを見つけることができるように、PC-lintは「マルチパス」分析モデルを使用して、このタイプのエラーに必要な検索深度を設定できます。 デフォルトでは、検索の深さは1ですが、機能間の関係に関連するほとんどの問題を診断するには、検索の深さ2が必要です。このメカニズムの操作の詳細については、PC-lintユーザーマニュアル、および公式Webサイトとデモサイトを参照してくださいオンラインデモページ。 キー-passes = 2でPC-lintを起動すると（オンラインデモの例では自動的に登録されます）、次の結果が得られます。

 During Specific Walk: line 7: test_buffer_overrun([4]) #1 2 Warning 415: Likely access of out-of-bounds pointer (1 beyond end of data) by operator '[' [Reference: file ipa2.c: lines 2, 7] 2 Info 831: Reference cited in prior message 7 Info 831: Reference cited in prior message
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージN415は、オーバーフローが発生したことを警告すると同時に、それが発生した配列の範囲外、およびコードのどのセクションの実行がエラーにつながったかを示します。 最後の2つのメッセージ（N831）はオプションであり、開発環境や他のアプリケーションで認識できる標準形式で警告テキストを表示するために使用されます。 次の例では、同じ情報がすでにメインメッセージに含まれているため、スペースを節約するためにN831メッセージが（ -e831パラメーターを介して）無効にされています。

バッファオーバーフロー（動的）

 typedef unsigned long size_t; void* malloc(size_t); void test_buffer_overrun(int p[]) { p[4] = 1729; } void test_driver(void) { int *p = malloc(4); test_buffer_overrun(p); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前のケースと同様に、この例では、PC-lintがエラーを検出できないと誤って主張しています。



前の例のように、静的に割り当てられたバッファのオーバーフローを検出できないのと同じ理由で、PC-lintはそのようなエラーを検出できません。



-passes = 2パラメーターを指定したPC-lintでこのコードをチェックすると、次の結果が得られます。

 During Specific Walk: line 10: test_buffer_overrun([1]? | 0?) #1 5 Warning 662: Possible creation of out-of-bounds pointer (4 beyond end of data) by operator '[' [Reference: file ipa3.c: lines 5, 9, 10] During Specific Walk: line 10: test_buffer_overrun([1]? | 0?) #1 5 Warning 613: Possible use of null pointer 'p' in left argument to operator '[' [Reference: file ipa3.c: lines 9, 10] During Specific Walk: line 10: test_buffer_overrun([1]? | 0?) #1 5 Warning 661: Possible access of out-of-bounds pointer (4 beyond end of data) by operator '[' [Reference: file ipa3.c: lines 5, 9, 10]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-lintは、バッファーの境界を越えて指すポインターが作成された場所と使用されている場所の両方を検出し、このポインターのnullをチェックします（malloc関数はnullを返すことができますが、この例はチェックされません）。



警告テキストの前のtest_buffer_overrun（[1]？| 0？）＃1呼び出しの詳細な説明は、メッセージが表示される前のコード実行パスを示しています。 この場合、 test_buffer_overrun関数の呼び出しを検討します。この関数では、1つの要素の配列を指すポインターが渡される（たとえば、 int型の単一の値から）か、nullポインター（ 0？ ）です。 疑問符は、nullの値がチェックされていないため、これら2つのオプションのどちらが実際に行われるかが不明であることを意味します。 したがって、PC-lintは単に問題を診断するだけでなく、特定の結論に至った経緯を説明します。

NULLポインターの逆参照

 #define NULL (void *)0 void test_deref(int *p) { *p = 55; } void test_driver(void) { int *pi1 = NULL; test_deref(pi1); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして再び、レポートの著者は、PC-lintの与えられた例は彼らの力を超えていると宣言します：



これはおそらく、2つのプロシージャを使用してNULLポインターを逆参照する最も単純な例です。 CodeSonarのみがこのようなエラーを見つけることができます。



繰り返しますが、このステートメントは-passes = 2パラメーターを含めることで反論することができます。

 During Specific Walk: File ipa4.c line 9: test_deref(0) #1 4 Warning 413: Likely use of null pointer 'p' in argument to operator 'unary *' [Reference: file ipa4.c: lines 8, 9]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-lintは、nullポインター逆参照警告を発行し、それが発生する方法と理由を説明します。

メモリリーク

 typedef unsigned long size_t; void *malloc(size_t); void free(void *); void test_free(int *p, int x) { if (p && x < 10) free(p); } void test_driver(void) { int *pi1 = malloc(20); test_free(pi1, 20); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、レポートには次のように記載されています。



この例では、あるプロシージャでバッファが割り当てられ、別のプロシージャでバッファが解放されます。ただし、特定の条件が満たされた場合のみです。 このエラーはCodeSonarでのみ見つけることができます。



ただし、 -passes = 2パラメーターを指定してPC-lintを実行すると、 そうではないことがわかります。

 During Specific Walk: line 11: test_free([5]? | 0?, 20) #1 8 Warning 429: Custodial pointer 'p' (line 5) has not been freed or returned
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-lintは、このエラーを検出し、警告を引き起こした呼び出しの詳細な要約を提供できました。

音声コメント

各ツールには長所と短所があり、特定のツールの短所を知っていれば、それらを強調するための人為的な例を見つけることは難しくありません。 レポートでは、PC-lintのよく知られている欠点ではあるが、実際の欠点を悪用する、非常に慎重に設計されたコード例を見つけることができます。 これらの例のほとんどは、ポインター関連のデータを追跡するPC-lintの機能の制限を明らかにしています。 データ追跡システムはPC-lint Plus（PC-lintの開発の次のステップ。アプリケーションは現在ベータテスト中）で最終決定され、これらの制限はなくなりました。 以下の例はPC-lintでは診断されませんが、PC-lint Plusを使用した分析結果を提示して、製品の改善に常に取り組んでいることを示します。

初期化されていない変数

 int foo() { int iret; int *p = &iret; return iret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-Lint Plusメッセージ：

 4 warning 530: likely using an uninitialized value return iret; ^ 2 supplemental 891: allocated here int iret; ^
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

解放されたメモリへのアクセス

 typedef unsigned long size_t; void *malloc(size_t); void free(void *); void foo() { char *p = (char *)malloc(10); char *q = p; if (p) { p[0] = 'X'; free(p); q[0] = 'Y'; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-lint Plusメッセージ：

 11 warning 449: memory was likely previously deallocated q[0] = 'Y'; ^ 10 supplemental 891: deallocated here free(p); ^ 6 supplemental 891: allocated here char *p = (char *)malloc(10); ^
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

二重メモリ割り当て解除

 typedef unsigned long size_t; void *malloc(size_t); void free(void *); void test_double_free(int *p) { if (p) free(p); } void test_driver(void) { int *pi1 = (int *)malloc(sizeof(int)); if (pi1) test_double_free(pi1); if (pi1) free(pi1); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PC-lint Plusメッセージ：

 15 warning 2432: memory was potentially deallocated free(pi1); ^ 15 supplemental 894: during specific walk free([4]@0/1) free(pi1); ^ 7 supplemental 891: deallocated here free(p); ^ 11 supplemental 891: allocated here int *pi1 = (int *)malloc(sizeof(int)); ^
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バッファオーバーフロー

 void foo() { char buffer[10]; char *pc; pc = buffer; for (int i = 0; i <= 10; i++) *pc++ = 'X'; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は、 forループでのバッファーオーバーフローを示しています。 状態値を追跡するためにPC-lintおよびPC-lint Plusで使用されるモデル（現時点では）は、このコードのiとpcの関係を考慮していません。 これは現在、PC-lintの客観的な欠点です。 CodeSonarの弱点を強調する同様の例を簡単に思い付くことができますが、それでは何も得られません。 上記のように、各ツールには長所と短所があり、各ツールは他人には見えないエラーを診断できることを認識しています。 他のアナライザーの欠点を指摘する代わりに、PC-lintのメリットに取り組み、ユーザーのニーズを満たすために製品を継続的に改善することを好みます。

まとめ

以下の表では、PCリントに関するGrammatechの主要な虚偽の申し立てと、私たちがそれらに反論する事実をまとめました。

虚偽の陳述	実際に
PC-lintは、Unixの元のlintファミリーの原始的なツールです。	PC-lintは、過去30年間にわたって他のツールとは独立して継続的に開発および改善された高度な静的アナライザーであり、受賞歴のある革新的な分析ツールを提供します。 それらの1つは、機能とモジュール間の転送中にデータを追跡するシステムです。
PC-lintは、最も明らかなエラーのみを検出できます。	PC-lintは、Grammartechレポートの例のエラーを含む、複雑なエラーを検出できる多くの高度な技術を使用しています
PC-lintは、大規模プロジェクトで重大なエラーを検索するようには設計されていません。	PC-lintは、数百行のコードから数百万行まで、あらゆる規模のプロジェクトで使用されています。
PC-lintはテキスト出力形式のみをサポートし、継続的統合ツールでの使用には適していません。	PC-lintは、プレーンテキスト、HTML、XMLを含むほぼすべてのレポート形式をサポートし、クライアントの経験が示すように、HudsonやJenkinsなどの継続的統合ツールを含む他のアプリケーションと組み合わせてさまざまな方法で使用できます。
PC-lintは、複雑なエラーを検索するときに警告をトリガーしたコードの実行パスを表示しません。	PC-lintは、可能な場合、結論に至った呼び出しのシーケンスや値などの詳細情報を提供します。
PC-lintは開発者専用です。	PC-lintは、その目的に応じて、ソフトウェア開発者、技術管理の専門家、テスター、および法医学の専門家によって使用されます。
PC-lintはファイル内の問題のみを認識できます。	PC-lintは、その存在の最初から、モジュール間の関係を含め、プログラム全体を分析する方法を知っています。 この機能は、とりわけ、他のツールと区別されました。
PC-lintは、考えられるすべてのソフトウェアエラーを見つけることができません。	静的アナライザーはすべてのエラーを診断できないため、PC-lintは、多くの複雑で実際のエラーを含む、検出された欠陥の大きな実績を持ち、その機能は改善され続けています。

おわりに

Gimpel Softwareは、ユーザーと競合他社の両方からの誠実なレビューと建設的な批判を歓迎しますが、レポートの著者による意図的な虚偽の記述は誠実でも建設的でもなく、プログラマーや静的分析業界の利益にはなりません。 Grammartechのポリシーは、競合製品に関する虚偽および軽rog的な発言に基づいており、競合他社ではなくこの会社を不利な立場に置いています。



レポートから結論できるように、PC-lintとCodeSonarの主な違いは次のとおりです。

• CodeSonarは緊密に統合されたグラフィカルインターフェイスを備えていますが、PC-lintは、Visual Studio、Eclipseなどの最新ツールとアナライザーを統合するための柔軟なオプションをユーザーに提供します。
• CodeSonarの範囲はPC-lintの範囲よりも狭いため、その機能は当社製品の機能よりも小さくなっています。
• CodeSonarには、PC-lintでまだサポートされていない多くの機能があります。 特に、このレポートではメトリック分析とペイント分析に言及しています-将来のバージョンのPC-lint Plus向けにこれらのメカニズムの両方を開発しています。 もちろん、PCリント機能の多くはCodeSonarにはありません。

翻訳者のメモ

以下に、アナライザーの比較について記述したくない理由の良い例を示します。 これも複雑な作業であり、主観的ではなく、さまざまな楽器を同じようによく知る必要があります。 幾分もっともらしい評価でさえ、多数のプロジェクトを異なるアナライザーでチェックした結果を比較する場合にのみ可能であると信じています。 しかし、これは多くのニュアンスを伴う非常に大きなタスクです。 他のすべての評価は主観的な意見に過ぎず、ここで見られるように、簡単に対立状況に発展する可能性があります。