PVS-Studioチームは、カスタム開発を行うことで視野を広げます

ご存知のように、私たちの主な活動はPVS-Studioコードアナライザーの開発です。 そして、私たちはこれを長い間行ってきましたが、私たちには思えるように、私たちはうまくやっていますが、最近、私たちは珍しいアイデアを思いつきました。 それでも、クライアントと同じモードでツールを使用することはありません。 いいえ、もちろん、PVS-Studioを使用してPVS-Studioコードをチェックします。 しかし、率直に言って、PVS-Studioプロジェクトはそれほど大きくありません。 また、PVS-Studioコードでの作業は、たとえばChromiumやLLVMコードでの作業とはスタイルや特徴が異なります。



当社のツールが長期プロジェクトでどのように使用されているかを理解するために、私たちはクライアントの立場になりたかったのです。 実際、私たちが定期的に行っているプロジェクトや多くの記事を書いているプロジェクトのチェックは、私たちが積極的に反対しているアナライザーの使用スタイルに過ぎません。 プロジェクトでワンタイムアナライザーを実行し、いくつかのエラーを修正し、1年後にこれを繰り返すのは間違っています。 コードを記述するとき、アナライザーは毎日定期的に使用する必要があります。



まあ、それは何のためですか？ 他のプロジェクトに挑戦したいという理論的な欲求は、徐々に提案され始めた実用的な提案と一致しました。 昨年、私たちは会社のチームを選び出しました-ホラー！ -カスタム開発。 つまり、彼女はサードパーティのプロジェクトにプログラマーとして参加しました。 そして、長期的でかなり大規模なプロジェクトに参加することは興味深いものでした。 少なくとも2〜3人の開発者と少なくとも6か月の開発。 2つの目標がありました。

• 別のタイプのビジネス（製品開発に加えてカスタム開発）を試してください。
• 長期プロジェクトでのPVS-Studioの使用を自分で確認してください。

最初と2番目のタスクは両方とも成功しました。 しかし、この記事はカスタム開発のビジネスについてではなく、私たちの経験についてです。 これは組織的な経験ではありません。 これについては非常に多くの記事があります。 他の人のプロジェクトのコードを扱った経験について。 これについて話したいです。

興味深い点

サードパーティのプロジェクトは多くのことを教えてくれます。 このトピックに複数の記事を捧げると思います。 次に、興味深い観察から始めます。 大規模で古いプロジェクトにあることが判明したコードの3つの明るい機能に気付きました。 時間が経つにつれて、他の観察結果についての出版物が出ると確信しています。



プラットフォームの容量を32ビットから64ビットに変更することに関する記事がたくさんあります。 多くのエラーは移植に関連しており、64ビットプログラムに現れ始めます。 64ビットエラーと呼びます。



ただし、64ビットシステムへの移行に加えて、コードにはそれほど目立たない変更が加えられています。 これは、コンパイラ、ライブラリの開発、およびプロジェクト自体の成熟に関連して起こりました。 これらの変更の結果は、長い開発履歴を持つコードではっきりと見えます。 それらについて議論することをお勧めします。 私はそれが面白くて便利になると思います。 誰かが古いコードを確認して、同様の問題を特定したいと思うかもしれません。



考慮されたエラーパターンは、PVS-Studioアナライザーのおかげで気づきました。 これらのエラーの多くは隠されています。 コードは、運のおかげでほとんど機能します。 ただし、このようなミスはすべて、いつでも発砲できる小さな時限爆弾です。



ご注意 NDAの制限を回避するために、名前を変更し、コードを編集しました。 実際、これはプログラムにあったコードではありません。 ただし、「すべては実際のイベントに基づいています」。

新しいオペレーターの動作の変更

昔々、「new」演算子はメモリ割り当てエラーの場合にNULLを返しました。 その後、コンパイラは最新のC ++標準をサポートし始め、そのような状況でstd :: bad_alloc例外をスローしました。 「new」演算子に強制的にNULLを返すことができますが、今はこれがポイントではありません。



どうやら、これらの変更はプログラマのコミュニティによって非常に表面的に気づかれたようです。 この事実に注意し、新しい動作を考慮してコードを書き始めました。 もちろん、「新しい」演算子が例外をスローすることをまだ知らないプログラマーもいます。 しかし、私たちは通常の適切なプログラマーについて話している。 20年前のように、何も知りたくなく、スタイルを書き続けたいと思う人は、私たちには興味がありません。



ただし、「新しい」演算子が動作を変更したことを知っている人でも、既存のコードを確認していません。 誰かが単に気づかなかった。 誰かが望んでいましたが、彼には時間がありませんでした、そして、それを忘れました。 その結果、メモリを割り当てることができない状況の誤ったプロセッサは、膨大な数のプログラムで生き続けます。



一部のコードは無害です。

int *x = new int[N]; if (!x) throw MyMemoryException(); // 1 int *y = new int[M]; if (!y) return false; // 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のケースでは、MyMemoryExceptionの代わりにstd :: bad_alloc例外がスローされます。 ほとんどの場合、これらの例外は同じ方法で処理されます。 問題ありません。



2番目の場合、チェックは機能しません。 関数は値「false」を返しません。 代わりに、後で処理される例外が発生します。 これは間違いです。 プログラムの動作が変更されました。 しかし実際には、これはほとんど問題につながりません。 プログラムがメモリ不足に対して少し異なる反応をするだけです。



プログラムの動作が少しだけではなく、非常に大きく変化する場合について警告することがより重要です。 大規模な古いプロジェクトには、このような状況がたくさんあります。



十分なメモリがないときに特定のアクションを実行する必要がある場合の例を次に示します。

 image->SetBuffer(new unsigned char[size]); if (!image->GetBuffer()) { CloseImage(image); return NULL; } FormatAttribute *pAttrib = new FormatAttribute(sName, value, false); if (pAttrib ) { m_attributes.Insert(pAttrib); } else { TDocument* pDoc = m_state.GetDocument(); if (pDoc) pDoc->SetErrorState(OUT_OF_MEMORY_ERROR, true); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなコードははるかに危険です。 たとえば、メモリ不足の場合、ユーザーはドキュメントの内容を失う可能性がありますが、ドキュメントをファイルに保存する機会を与えることはかなり可能です。



推奨事項。 プログラム内のすべての「新しい」ステートメントを見つけます。 ポインターがゼロの場合、プログラムが何らかのアクションを実行するかどうかを確認します。 そのような場所を書き直してください。



PVS-Studioアナライザーは、 V668診断を使用して意味のないチェックを検出するのに役立ちます。

char *をstd :: stringに置き換える

CからC ++への移行と標準ライブラリの人気の高まりにより、std :: stringなどの文字列クラスがプログラムで広く使用されるようになりました。 これは理解でき、理解できます。 char *ポインターではなく、本格的な文字列を使用する方が簡単で安全です。



文字列クラスは、新しいコードだけでなく、いくつかの古いフラグメントの変更にも使用され始めました。 これによりトラブルが発生する可能性があります。 注意を弱めるだけで十分であり、コードが危険になったり完全に不正になったりします。



しかし、怖いからではなく、楽しみから始めましょう。 このような非効率的なループが発生する場合があります。

 for (i = 0; i < strlen(str.c_str()); ++i)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、変数 'str'が通常のポインターであった場合。 ループの各反復でstrlen（）関数を呼び出すのは良くありません。 これは長い行では非常に非効率的です。 しかし、ポインターをstd :: stringに変えた後、コードはさらに愚かに見え始めました。



型の変更が軽率に行われたことはすぐにわかります。 これにより、同様の非効率的なコードやエラーが発生する可能性があります。 間違いについて話しましょう：

 wstring databaseName; .... wprintf("Error: cannot open database %s", databaseName); // 1 CString s; .... delete [] s; // 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のケースでは、ポインター「wchar_t *」が「wstring」に変わりました。 データベースを開くことができず、メッセージを印刷する必要がある場合、問題が発生します。 コードはコンパイルされますが、アブラカダブラが画面に印刷されます。 または、プログラムは通常クラッシュします。 理由-c_str（）への呼び出しを追加するのを忘れた。 正しいオプション：

 wprintf("Error: cannot open database %s", databaseName.c_str());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のケースは一般的に壮大です。 驚くことではありませんが、そのようなコードは正常にコンパイルされます。 非常に人気のある文字列クラスCStringが使用されます。 CStringクラスは暗黙的にポインターに変換できます。 これがここで起こっていることです。 その結果、ダブルバッファーが削除されます。



推奨事項。 ポインターを文字列クラスに変更する場合は、慎重に行ってください。 各ケースを確認せずにバルク交換を使用しないでください。 コードがコンパイルされるからといって、それが機能するとは限りません。 コードを編集する必要がない場合は、ポインタのみを使用してコードを残すことをお勧めします。 コードがクラスで誤って動作するよりも、ポインタで正しく動作する方が適切です。



PVS-Studioアナライザーは、クラスポインターの置換が原因で発生したエラーの一部を検出するのに役立ちます。 これには、 V510 、 V515などの診断が役立ちます。 しかし、アナライザーに完全に依存することは価値がありません。 非常に創造的なコードをキャッチできます。この場合、エラーはアナライザーだけでなく、経験豊富なプログラマーでも見つけることができます。

charをwchar_tに置き換える

プロジェクトは開発中であり、アプリケーションインターフェイスを多言語にしたいという要望があります。 また、ある時点で、charがwchar_tに大量に置き換えられます。 コンパイラーによって生成されたエラーを修正しました。 アプリケーションの「準備完了」ユニコードバージョン。



実際には、このような交換の後、アプリケーションはふるいに変わります。 そのような交換後に発生するエラーは、数十年にわたって現れ、再現するのが困難です。



これはどのようにできますか？ とても簡単です。 多くのコードは、文字のサイズを変更する準備ができていません。 コードはエラーや警告なしでコンパイルされます。 ただし、「50％」でのみ機能します。 これで、私たちの意味を理解できます。



ご注意 学生から受け取った悪いコードに脅かされていないことを思い出させてください。 プログラマー生活の厳しい現実について話しています。 大規模で古いプロジェクトでは、このようなエラーは必然的に発生します。 そして、それらは何百もあります。 真剣に。 数百



例：

 wchar_t tmpBuffer[500]; memset(tmpBuffer, 0, 500); // 1 TCHAR *message = new TCHAR[MAX_MSG_LENGTH]; memset(charArray, 0, MAX_MSG_LENGTH*sizeof(char)); // 2 LPCTSTR sSource = ...; LPTSTR sDestination = (LPTSTR) malloc (_tcslen(sSource) + 12); // 3 wchar_t *name = ...; fprintf(fp, "%i : %s", i, name); // 4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前者の場合、プログラマーはキャラクターのサイズが時間とともに変化するとはまったく考えていませんでした。 したがって、バッファーの半分のみをクリアしました。 それが私の言葉の約50％の由来です。



2番目のケースでは、プログラマーはキャラクターのサイズが変わると推測しました。 ただし、「* sizeof（char）」というヒントは、大量の型の置換には役立ちませんでした。 間違ったことをする必要がありました。 正しいオプション：

 memset(charArray, 0, MAX_MSG_LENGTH * sizeof(charArray[0]));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3番目の例。 型はすべて問題ありません。 関数_tcslen（）は、文字列の長さを計算するために使用されます。 一見、すべてが素晴らしいです。 ただし、文字のタイプが「wchar_t」になり始めると、プログラムは再び50％で動作し始めました。



必要なメモリの2倍のメモリが割り当てられます。 実際、メッセージの長さが可能な最大長の半分を超えるまで、プログラムは正常に動作します。 長い間コードに残っていた不快なエラー。



4番目の例。 printf（）、sprintf（）などを修正しましたが、frintf（）の確認を忘れていました。 その結果、ごみがファイルに書き込まれます。 次のようなことをする必要がありました。

 fwprintf(fp, L"%i : %s", i, name);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、通常のASCIIファイルの場合：

 fprintf(fp, "%i : %S", i, name);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご注意 今、私はWindowsの観点から、約50％を話していると思った。 Linuxでは、wchar_t型は2バイトではなく4バイトを使用します。 したがって、Linuxの世界では、プログラムは一般に25％しか動作しません:)。



推奨事項。 既にcharをwchar_tに大量に置き換えている場合、何が役立つかわかりません。 これは多くの興味深い間違いを犯す可能性があります。 wcahr_tが使用されているすべての場所を綿密に確認することは現実的ではありません。 部分的には、静的コードアナライザーが役立ちます。 彼はいくつかのエラーを明らかにします。 上記のエラーは、PVS-Studioアナライザーによって検出されます。 charをwchar_tに置き換えることの結果は非常に多様であり、さまざまな診断で明らかになります。 それらをリストするのは意味がありません。 例として、 V512 、 V576 、 V635などに名前を付けることができます。



まだ交換を行っていないが、計画している場合は、真剣にアプローチしてください。 タイプを自動的に置き換え、コンパイルエラーを修正するには、たとえば2日かかります。 コードを表示して同じ置換を手動で行うには、1桁長い時間がかかります。 たとえば、2週間を費やします。 しかし、これは2年後に新しいエラーをキャッチするよりも優れています。

• 文字列の誤ったフォーマット。
• 割り当てられたメモリバッファの境界を越える;
• 半分クリアされたバッファーで作業します。
• 半分にコピーされたバッファーを処理します。
• などなど。

おわりに

サードパーティのカスタムメイドの開発に参加した経験に満足しているため、世界をさまざまな目で見ることができました。 開発者としてサードパーティのプロジェクトに引き続き参加しますので、このトピックについて誰かと話したいと思ったら書いてください。 後であなたについての明らかな記事が見つかることを恐れている場合（見つかったエラーについて）、とにかく書き込みます-NDAが私たちすべてを助けてください！