C ++コードの静的分析用ユーティリティの分析

次のユーティリティの分析：

• RATS（セキュリティ用の大まかな監査ツール）
• Cppcheck
• グラディット

必要なものはすべて、リンクをクリックして見つけることができ、すぐにビジネスに取りかかります。

テスト1：

int main() { vector<int> v; v.reserve(2); assert(v.capacity() == 2); v[0]; v[0] = 1; v[1] = 2; cout << v[0] << endl; v.reserve(100); cout << v[0] << endl; return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを注意深く調べて、いくつの問題を特定できますか？

もちろん、必要なヘッダーはすべて含まれています（ iostream、vector、cassert ）。

このコードのプロフェッショナルバージョンについて説明する前に、ソースコードの静的分析のための有名なユーティリティを分析します。 以下は、上記のユーティリティの結果です。



ラット ： なし

Cppcheck ： なし

グラウディット ： なし

g ++（-Wallフラグ付き） ： なし



一見するとそれほど悪くないのでしょうか、それとも何も悪いことはないのでしょうか？ Sutterでこれを言わないでください（とりわけ、彼の著書「C ++の新しい複雑な問題。ソリューションを用いた40の新しいパズルの例」から例を引用しています ）。

main（）関数の本体の最初の行で、整数で構成されるベクトルvを宣言します。 次に、2つの要素の場所を予約します。 次の行に進む前に、C ++標準を見てください。 彼女はvector :: reserveメソッドについて何を教えてくれますか？ （警告：無料翻訳）

」

 void reserve(size_type n);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サイズの計画的な変更について通知し、場合によってはメモリ割り当てを制御します。 reserve（）の後、容量（）は 、メモリの再割り当ての場合にreserve（）に渡される引数以上です。 それ以外の場合、 容量の前の値（）と等しくなります。 容量（）の現在の値がreserve（）引数の値より小さい場合にのみ、メモリの再分配が発生します。 コンテナのサイズは変更されず、最悪の場合、線形ランタイムが必要です。 引数値がmax_size（）より大きい場合、long_error例外をスローします。 再配布される場合、コンテナ要素を参照するすべての参照、ポインタ、およびイテレータを無効にします。



これで十分ですが、先に進みましょう。 文字列アサート（v.capacity（）== 2）; せいぜい、悪い、最初のリザーブ（）は容量の増加を保証します。この場合、 assertはコードの追加行にすぎません（「プログラマー」は、各操作の後にやみくもにアサートを信じ、プロフェッショナルなトーンと見なします）。 第二に、標準自体から学んだように、 reserve（）は指定された引数よりもコンテナ容量を増やすことができるため、Satterはassert（v.capacity（）> = 2）を推奨しています。 完全に削除することをお勧めします。

さらに悪い。 「 ベクトル<T> ::演算子[]演算子は、範囲チェックを実行できますが、必須ではありません。 標準ではこれについては何も言及されていないため、標準ライブラリの開発者は、このようなチェックを追加し、それを行わないすべての権利を持っています 。 すべての理由は効率であり、テストには時間がかかります。このようなチェックを多数行うと、プログラムの時間のかなりの部分が必要になります。 しかし、これは、効果的なプログラムがVasyaの信頼できるプログラムよりも優れているという意味ではありません。 行v [0]を置き換えてみてください。 v.at（0）; プログラムは例外を使用して飛行します。 ほとんどの場合、信頼できるコードが必要です。 vector <T> :: atは、インデックス値の範囲チェックを実行します。 このような状況でのみではなく、この方法を使用することを強くお勧めします。



行v [0] = 1; v [1] = 2; かなりうまく機能しているので、例をコンパイルすることで納得できます。 ただし、 サイズ/サイズ変更と予約/容量の違いを覚えておく必要があります。 resizeは、コンテナ内の要素の数を、コンテナの末尾から追加または削除することにより、指定された引数値に変更します。 予約メソッドについては標準から学びましたが、指定された数の要素を（少なくとも）収容できるように内部バッファのサイズを増やすことを追加しました。 「 演算子[] （またはatメソッド）を安全に使用できるのは、コンテナに実際に含まれている、つまり実際にサイズが考慮されている要素を変更する場合のみです。 」 そのため、静的解析ユーティリティも明確ではありません。 しかし、問題は重大です。 Sutterや他の多くのプロは、お気に入りのC ++でのコーディングの微妙なポイントについて本に書いています。 一見すると、言語の構文の問題と知識を解決する能力は開発には十分すぎるように思えるかもしれません。 しかし、あなたと私は、私たちが自分自身をだましていることを知っています。問題を特定するために、コードの各行に何人の人がコードを挿入しましたか？ 3日目に既に実行されたデバッグに耐えられなかった人は何人いましたか？ ですから、Sutter and Myers（および他の多くの）の達人による本を勉強したり勉強したりするのが面倒ではないプロのプログラミングスキルを持つ人々を含め、そのようなことに固有ではない人々がいます。



それでも、例1では、最後の論理エラー、 cout << v [0]の出力をどう思いますか。 予約後（100） ？ そうです、せいぜいゼロ！ 予約の前にv [0]にゼロ以外の値を指定したことに注意してください。 「問題」は再びバックアップ機能にあります。

それでは、一般的な場合の問題は何ですか？ v.reserve（2）の場合にそれを伝えるユーティリティが必要であるという事実。 v [0] = 1; v.resize（2）を使用することをお勧めします。 v [0] = 1; またはv.reserve（2）; v.push_back（1） ！ そして、私たちが検討したユーティリティは黙って黙っていました。 不正な境界をチェックするユーティリティも必要です。vの場合は[0]。 v.at（0）を使用することをお勧めします。 そして、私たちのレビューされたユーティリティは再び静かに素晴らしかったです。 したがって、微妙な状況では、道徳はRATS、Cppcheckなどのユーティリティに依存せず、さらにはGrauditにも依存します。 最高レベルの警告がオンになっているコンパイラーでさえ、時には偏執的なエンコーダーの目を通して見るべきです。

まあ、ユーティリティがネジに取って代わることは無駄ではありません。開発者がそれに取り組んだのは何の理由もありません。

テスト2：

さらに進んで、コードのエラーの量を増やしてください。 新しいprettyFormat関数を使用した同じコードを検討してください（Satterの例）。 彼女は番号とバッファを取得し、sprintfを使用して結果のバッファにその番号を挿入します。

 void prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); } int main() { vector<int> v; v.reserve(2); //.... char buf[5]; prettyFormat(10, buf); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、 prettyFormatが追加され、文字列char buf [10] が追加されました。 前の例のコードはもう必要ありませんが、そのままにしておきますが、ユーティリティの1つが何かを見るかもしれません。 結果は次のとおりです。



RATS： 行char buf [5]; 「 高：固定サイズのローカルバッファー。スタックに割り当てられた文字配列が安全に使用されるように特に注意する必要があります。これらはバッファーオーバーフロー攻撃の主なターゲットです。 」文字配列を使用する場合は無力なので、注意することをお勧めしますバッファオーバーフロー攻撃。

Cppcheck ： なし

グラウディット ： なし

g ++（-Wallオプション付き） ： なし



バッファオーバーフローについて多くのことが言われているので、簡単に批判します。 静的解析のツールは、バッファオーバーフローの可能性のあるケースを見つけることのみを目的としているという印象を持っています。 ただし、そのような場合でも（CppcheckやGrauditなど）、それらのいくつかはサイレントです。 私はコンパイラを非難せず、問題を見つけることを私に止めさせませんでしたが、ほとんどの場合、そのようなことのために特別に設計されたユーティリティはとても静かです。 このような状況では、 sprintfの代替を使用するために、ユーティリティから警告と推奨事項を取得する必要があります（他の可能な機能について）。 代わりの状況はSatterで読む必要があります（ std :: stringstream、std :: strstream、boost :: lexical_castについて話しますが、後者はstd :: stringstreamに基づいています。バッファオーバーフローから）。

テスト3：

初期化されていないポインターをprettyFormat関数に追加します。

 int* prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); int* a; return a; } int main() { ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインコードでは、以前のテストと比較して変更されていません。 これは深刻なテストのように思えるかもしれませんが、使用されるユーティリティに関する多くの興味深い情報を提供します。 特に、Cppcheckについてはコンパイラの警告を複製しないと言われましたが、すぐにわかるように、それはブラフです。 そして、他のユーティリティは単に問題を認識しないか、実際にコンパイラの警告を複製しません。 以下がその結果です。



RATS ： 前のテストと同じ（文字列char buf [5];について話している）

Cppcheck ： 行int * a; throws（error）初期化されていない変数：a。

結構ですが...

g ++（- Wall オプションを使用） ： 関数 'int * prettyFormat（int、char *）'：

警告： 'a'はこの関数で初期化されずに使用されます。

なじみのあるものはありませんか？ Cppcheckが最終的に出したのと同じ警告。

Grauditは 一般的に沈黙しています。

テスト4：

ユーモアを追加し、 prettyFormat関数を次のように変更します。

 int* prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); int* a; fopen("filename", "r"); char buf2[5]; strcpy(buf2, buf); return a; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Fopenが追加されました。これは、ローカルのbuf2バッファーが追加されたことを知りません。引数として受信したbufがstrcpyを使用してコピーされます。 誰がいくら与えるか見てみましょう。



RATS： 文字列char buf2 [5]; char buf [10]固定サイズの文字バッファの使用に関する注意についての同じ警告。

そして最後に：「高：strcpy

この関数呼び出しに渡された引数2がコピーされないことを確認してください

処理可能なデータよりも多くのデータがあり、バッファオーバーフローが発生します。」

2番目の引数がbuf2が含むことができるよりも多くのデータをコピーするかどうかを確認します。

悪くはありませんが、多くの状況で役立ちます。 さらに進みましょう。

Cppcheck ：（ エラー）ユニット化された変数：a。

前の例と同じですが、ごめんなさい。

g ++（-Wallオプションを使用） ： 前のテストと同じです。



RATSは多かれ少なかれタスクに対処し、残りは-撃ちます！ なぜすべてがそんなに悪いのですか？ 第一に、これらのユーティリティを自分で書いた人は、実際にはC ++の達人ではありません。ほとんどの場合、プログラムを公開したいだけです。 第二に、微妙なエラーの多くは検出が難しく、商用ユーティリティによって主に処理されますが、私はまだ試していません。 第三に、本、雑誌、特にHabrを読んでください。これらのようなユーティリティは必要ありません。



ご清聴ありがとうございました！



PSコード改訂ブログを公開したかったのですが、カルマが十分ではありません。 いいえ、群衆が大声で叫ばない場合に備えて、「このようにカルマを増やしたいというわけではありません-「なぜここにないのか...」」



PPS Habrasocietyに感謝します-それを続けてください！