2015年の64ビットコード：起こりうる問題の診断の新機能

64ビットエラーは、時限爆弾に似ているため、検出するのが十分に困難です。すぐに感じられない場合があります。 PVS-Studio静的アナライザーを使用すると、このようなエラーを簡単に見つけて修正できます。 ただし、この方向でいくつかの手順が実行されました。最近、64ビット診断がより慎重に改訂され、その結果、重要度レベルによる分布が変更されました。 この記事では、これらの変更と、これがツールの動作とエラーの検索にどのように影響したかについて説明します。 実際のアプリケーションからの64ビットエラーの例が含まれています。

についての記事は何ですか？

まず、コンテンツの詳細を紹介したいと思います。 この記事では、次のトピックについて説明します。

1. 64ビットエラーの検索に影響するPVS-Studioアナライザーの変更。
2. PVS-Studioアナライザーによって検出された64ビットの第1レベルエラーのレビュー、およびそれらに関する簡単なコメント。
3. PVS-StudioとMicrosoft Visual Studio 2013を使用して最も重要なエラーを見つける際の有効性の比較。

最初の段落はそれ自身を物語っています：64ビットエラーの分析に関するPVS-Studioの主な変更と、それらがツールの動作にどのように影響するかを考慮します。



2番目のメインセクションは、実際のプロジェクトで見つかった64ビットエラーに専念します。 プロジェクトのコードスニペットに加えて、コメントも提供されるため、自分で何か新しいことを学ぶことができます。



3番目のセクションでは、これらのエラーの検索の有効性をPVS-Studio静的アナライザーおよびMicrosoft Visual Studio 2013環境のツールと比較します。さらに、Visual Studioの場合、コンパイラーと静的アナライザーの両方を使用してエラーを検索しました。



いくつかのエラーのみがここに書き出されることを忘れないでください。 実際のプロジェクトでは、それらは確実にはるかに大きく、より多様になります。 記事の最後に、64ビットエラーの世界をより完全に紹介するリンクが提供されています。

64ビットエラーに関連するPVS-Studioの変更

少し前までは、64ビット診断を注意深く調べ、重要度レベルに応じてより正確に配布しました。



64ビットエラーの分布は次のようになります。



レベル1。アプリケーションに損害を与える重大なエラー。 例として、32ビットのint変数にポインターを格納します。 64ビットアプリケーションを開発している場合は、必ず最初のレベルの警告を調べて修正する必要があります。



レベル2。通常、大量のデータを処理するアプリケーションでのみ現れるエラー。 例は、巨大な配列にインデックスを付けるための「int」型変数の使用です。



レベル3。その他すべて。 原則として、これらの警告は関係ありません。 ただし、アプリケーションによっては、特定の診断が非常に役立つ場合があります。



したがって、第1レベルの64ビットエラーでフィルタリングすると、エラーの可能性が高いコードセクションを示すメッセージのリストが表示されます。 これらの警告を過小評価しないでください。64ビットエラーの結果は大きく異なる可能性がありますが、明らかに不快であり、しばしば予期しないものです。 私たちが話すのは彼らについてです。



PVS-Studioなどのツールなしでこのようなエラーを検出することはどれほど難しいでしょうか。この記事を読むと理解できると思います。

64ビットエラー分析

データ型が正しく使用されるように注意する必要があります。 おそらく、これから始めます。

LRESULT CSaveDlg::OnGraphNotify(WPARAM wParam, LPARAM lParam) { LONG evCode, evParam1, evParam2; while (pME && SUCCEEDED(pME->GetEvent(&evCode, (LONG_PTR*)&evParam1, (LONG_PTR*)&evParam2, 0))) { .... } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告：

• V114危険な明示的な型ポインター変換：（LONG_PTR *）＆evParam1 test.cpp 8
• V114危険な明示的なタイプポインター変換：（LONG_PTR *）＆evParam2 test.cpp 8

エラーの本質を理解するには、変数「evParam1」、「evParam2」のタイプ、および「GetEvent」メソッドの宣言を調べる必要があります。

 virtual HRESULT STDMETHODCALLTYPE GetEvent( /* [out] */ __RPC__out long *lEventCode, /* [out] */ __RPC__out LONG_PTR *lParam1, /* [out] */ __RPC__out LONG_PTR *lParam2, /* [in] */ long msTimeout) = 0;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーメッセージからわかるように、危険な明示的な型変換が実行されます。 実際には、タイプ 'LONG_PTR'は ' memsizeタイプ 'であり、Win32（ ILP32データモデル ） では 32ビット、Win64アーキテクチャ（ LLP64データモデル ） では 64ビットのサイズを持ちます。 同時に、「LONG」タイプは両方のアーキテクチャで32ビットです。 前述の型は64ビットアーキテクチャ上でサイズが異なるため、これらのポインターによって参照されるオブジェクトの誤った操作が可能です。



危険な型変換のトピックを続けます。 次のコードを見てください。

 BOOL WINAPI TrackPopupMenu( _In_ HMENU hMenu, _In_ UINT uFlags, _In_ int x, _In_ int y, _In_ int nReserved, _In_ HWND hWnd, _In_opt_ const RECT *prcRect ); struct JABBER_LIST_ITEM { .... }; INT_PTR CJabberDlgGcJoin::DlgProc(....) { .... int res = TrackPopupMenu( hMenu, TPM_RETURNCMD, rc.left, rc.bottom, 0, m_hwnd, NULL); .... if (res) { JABBER_LIST_ITEM *item = (JABBER_LIST_ITEM *)res; .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V204 32ビット整数型からポインター型への明示的な変換：（JABBER_LIST_ITEM *）res test.cpp 57



まず、このコードで使用されている「TrackPopupMenu」関数を見てみるといいでしょう。 ユーザーが選択したメニュー項目の識別子を返します。エラーの場合や選択肢がなかった場合はnull値を返します。 これらの目的で「BOOL」と入力すると、明らかに失敗しますが、どうすればよいですか。



この関数の実行結果は、コードからわかるように、変数「res」に入力されます。 それでも一部の要素がユーザーによって選択された場合（res！= 0）、この変数は構造体へのポインターにキャストされます。 興味深いアプローチですが、この記事では64ビットエラーについて説明しているので、このコードが32ビットおよび64ビットアーキテクチャでどのように実行されるか、そして何が問題になるのか考えてみましょう。



キャッチは、32ビットアーキテクチャでは、「ポインター」と「ブール」の型が同じサイズであるため、このような変換は受け入れ可能で実行可能であるということです。 しかし、このレーキは64ビットアーキテクチャで感じられます。 Win64アプリケーションでは、上記のタイプのサイズは異なります（それぞれ64ビットと32ビット）。 潜在的なエラーは、ポインターの最上位ビットが失われる可能性があることです。



レビューを継続します。 コードスニペット：

 static int hash_void_ptr(void *ptr) { int hash; int i; hash = 0; for (i = 0; i < (int)sizeof(ptr) * 8 / TABLE_BITS; i++) { hash ^= (unsigned long)ptr >> i * 8; hash += i * 17; hash &= TABLE_MASK; } return hash; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V205ポインター型から32ビット整数型への明示的な変換：（符号なしlong）ptr test.cpp 76



この関数で「void *」型の変数を「unsigned long」型にキャストする問題が何であるかを見てみましょう。 既に述べたように、これらのタイプはLLP64データモデルでサイズが異なり、「void *」タイプは64ビットを占有し、「unsigned long」は32ビットです。 この結果、変数「ptr」に含まれる上位ビットは切り捨てられます（失われます）。 この結果、変数 'i'の値は反復が進むにつれて増加します。反復が進むにつれてビット単位で右にシフトすると、増加するビット数に影響します。 変数 'ptr'のサイズは切り捨てられているため、ある反復から、それに含まれるすべてのビットが0で埋められます。上記のすべての結果-Win64ベースのアプリケーションでは、 'hash'は正しくコンパイルされません。 「ハッシュ」にゼロを入力すると、 衝突が発生する可能性があります。つまり、異なる入力データ（この場合はポインター）に対して同じハッシュを取得します。 その結果、これは非効率的なプログラム操作につながる可能性があります。 'memsize type'へのキャストが実行された場合、切り捨ては行われず、シフト（したがってハッシュのコンパイル）が正しく実行されます。



次のコードを見てみましょう。

 class CValueList : public CListCtrl { .... public: BOOL SortItems(_In_ PFNLVCOMPARE pfnCompare, _In_ DWORD_PTR dwData); .... }; void CLastValuesView::OnListViewColumnClick(....) { .... m_wndListCtrl.SortItems(CompareItems, (DWORD)this); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V220型キャストの不審なシーケンス：memsize-> 32ビット整数-> memsize。 キャストされる値： 'this'。 test.cpp 87



Diagnostics V220は、二重の危険なデータ変換を通知します。 最初に、「memsize type」の変数は32ビット値になり、すぐに「memsize type」に戻ります。 実際、これは最上位ビットの値が「カットオフ」されることを意味します。 これはほとんどの場合間違いです。



危険な変換のトピックについては、引き続き拡張します。

 #define YAHOO_LOGINID "yahoo_id" DWORD_PTR __cdecl CYahooProto::GetCaps(int type, HANDLE /*hContact*/) { int ret = 0; switch (type) { .... case PFLAG_UNIQUEIDSETTING: ret = (DWORD_PTR)YAHOO_LOGINID; break; .... } return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V221型キャストの疑わしいシーケンス：ポインター-> memsize- > 32ビット整数。 キャストされる値： '"yahoo_id"'。 test.cpp 99



私は、変換の各例でますます多くなる傾向に気づきました。 上記のすべてと同じ理由で、最大3つあり、そのうち2つは危険です。 「YAHOO_LOGINID」は文字列リテラルであるため、そのタイプは「const char *」であり、64ビットアーキテクチャでは「DWORD_PTR」タイプと同じサイズであるため、明示的な変換は正しいです。 しかし、その後、悪いことが始まります。 型「DWORD_PTR」は、暗黙的に32ビット整数にキャストされます。 しかし、それだけではありません。 関数によって返される結果は 'DWORD_PTR'タイプであるため、別の暗黙的な変換が実行され、今回は 'memsizeタイプ'に戻ります。 明らかに、この場合、戻り値の使用はあなた自身の責任です。



Visual Studio 2013コンパイラが次のような警告を発行したことに注意してください。



警告C4244：「=」：「DWORD_PTR」から「int」への変換、データの損失の可能性



実際の質問はここで可能になります：Visual Studio 2013によって発行された警告がこの例でのみ表示されるのはなぜですか？ 質問は公平ですが、忍耐強く、これは以下に書かれます。



それまでの間、エラーの検討を続けています。 クラス階層を含む次のコードを検討してください。

 class CWnd : public CCmdTarget { .... virtual void WinHelp(DWORD_PTR dwData, UINT nCmd = HELP_CONTEXT); .... }; class CFrameWnd : public CWnd { .... }; class CFrameWndEx : public CFrameWnd { .... virtual void WinHelp(DWORD dwData, UINT nCmd = HELP_CONTEXT); .... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V301予期しない関数のオーバーロード動作。 派生クラス「CFrameWndEx」および基本クラス「CWnd」の関数「WinHelpA」の最初の引数を参照してください。 test.cpp 122



例は、Visual C ++ 2012ライブラリをチェックするときにレポートから取得されるという点で興味深いですが、ご覧のように、Visual C ++開発者でさえ64ビットエラーを作成します。



このエラーに関する詳細は、 対応する記事に記載されています 。 ここでその本質を簡単に説明したかった。 32ビットアーキテクチャでは、「DWORD」と「DWORD_PTR」のタイプが同じサイズであるため、このコードは正しく処理されます。後継クラスでは、この関数がオーバーライドされ、コードが正しく実行されます。 しかし、落とし穴はまだここにあり、64ビットアーキテクチャで自分自身について知ることができます。 この場合、タイプ「DWORD」と「DWORD_PTR」のサイズは異なるため、ポリモーフィズムは破棄されます。 2つの異なる機能を手元に用意しますが、これは意図したものに反します。



そして最後の例：

 void CSymEngine::GetMemInfo(CMemInfo& rMemInfo) { MEMORYSTATUS ms; GlobalMemoryStatus(&ms); _ultot_s(ms.dwMemoryLoad, rMemInfo.m_szMemoryLoad, countof(rMemInfo.m_szMemoryLoad), 10); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーの警告： V303関数 'GlobalMemoryStatus'は、Win64システムでは非推奨です。 'GlobalMemoryStatusEx'関数を使用する方が安全です。 test.cpp 130



原則として、特別な説明は必要ありません。アナライザーのメッセージからすべてが明らかです。 「GlobalMemoryStatus」関数は64ビットアーキテクチャでは正しく動作しない可能性があるため、「GlobalMemoryStatusEx」関数を使用する必要があります。 詳細については、MSDN の対応する関数の説明を参照してください。



ご注意



上記のエラーはすべて、最も一般的なアプリケーションソフトウェアで発生する可能性があることに注意してください。 それらが発生するために、プログラムは大量のメモリで動作する必要はありません。 そして、それがこれらのエラーを検出する診断が最初のレベルに属する理由です。

Visual Studio 2013は何を伝えますか？

コンパイラの警告

Visual Studio 2013で静的アナライザーをチェックした結果について説明する前に、コンパイラーの警告について詳しく説明します。 気配りのある読者は、おそらくこのような警告がテキストで1つだけ与えられていることに気づいたでしょう。 問題は何ですか？ しかし、実際には、64ビットエラーに関連する警告はもうありませんでした。 そして、これは警告を発行する第3レベルです。



ただし、すべての警告を有効にして（EnableAllWarnings）、この例をコンパイルする価値があります。











さらに、非常に予期せず、警告がヘッダーファイル（winnt.hなど）につながります。 あなたがあまりにも怠zyではなく、この警告の山でプロジェクトに関連するものを見つけた場合、あなたはまだ何か面白いものを抽出することができます、例えば：



警告C4312： '型キャスト'： 'int'から 'JABBER_LIST_ITEM *'への大きなサイズの変換



警告C4311：「型キャスト」：「void *」から「unsigned long」へのポインターの切り捨て



警告C4311：「型キャスト」：「CLastValuesView * const」から「DWORD」へのポインターの切り捨て



警告C4263： 'void CFrameWndEx :: WinHelpA（DWORD、UINT）'：メンバー関数は、基本クラスの仮想メンバー関数をオーバーライドしません



一般に、コンパイラはこれらの例を含むファイルで10個の警告を発行しました。 このリストの3つの警告のみが64ビットエラーを明確に示しています（コンパイラ警告C4311およびC4312）。 これらの警告の中には、絞り込み型変換（C4244）を示すものや、仮想関数がオーバーライドされないもの（C4263）があります。 これらの警告は、64ビットエラーも間接的に示しています。



その結果、何らかの方法で繰り返し繰り返される警告を除外すると、検討中の64ビットエラーに関する5つの警告が表示されます。



ご覧のとおり、Visual Studioコンパイラはすべての64ビットエラーを検出できませんでした。 PVS-Studioアナライザーが同じファイルで最初のレベルの9つのエラーを検出したことを思い出します。



「しかし、Visual Studio 2013に組み込まれている静的アナライザーはどうですか？」 たぶん、彼はより良くして、より多くの間違いを見つけましたか？ 見てみましょう。

Visual Studio 2013に含まれる静的アナライザー

Visual Studio 2013に組み込まれた静的アナライザーでこれらの例をチェックした結果、3つの警告がありました。

• C6255 allocaの保護されていない使用
  
  _allocaは、スタックオーバーフロー例外を発生させることで失敗を示します。 代わりに_mallocaの使用を検討してください。
  
  64BitsErrors-test.cpp（58行目）;
• C6384ポインターサイズの分割
  
  ポインターのサイズを別の値で除算します。
  
  64BitsErrors-test.cpp（行72）;
• C28159代わりに別の関数の使用を検討してください
  
  「GlobalMemoryStatus」の代わりに「GlobalMemoryStatusEx」の使用を検討してください。 理由：廃止されました。 詳細については、MSDNを参照してください
  
  64BitsErrors-test.cpp（128行目）;

しかし、私たちは64ビットエラーを見ていますよね？ このリストからいくつのエラーが64ビットに適用されますか？ 後者のみ（誤った結果を返す可能性のある関数を使用）。



Visual Studio 2013静的アナライザーは、PVS-Studioアナライザーによって検出された9に対して1 64ビットエラーを検出したことがわかりました。 印象的ですね。 大規模なプロジェクトの違いを想像してください。



そして、エラー検出に関する機能の観点から、Visual Studio 2013環境とVisual Studio 2015環境に組み込まれた静的コードアナライザーは同じであることをもう一度思い出しておきます（詳細については、 対応する注で説明します）。

結果は何ですか？

最も明確なのは、コード例の検証結果を表形式で反映することです。











表からわかるように、9個の64ビットエラーがPVS-Studioを使用して検出され、6個がMicrosoft Visual Studio 2013の一般的な手段によって検出されました。おそらく、これはそれほど大きな違いではないでしょう。 私は同意しません。 理由を理解しましょう：

• 最も重要な64ビットエラーについてのみ説明しました。 ミスしたエラーが3つでも、これはたくさんあります。 そして、PVS-Studioアナライザーが第2および第3レベルの警告を生成する、よりまれなエラーを取得すると、Visual Studioよりもはるかに多くのエラーを見つけることができます。 これについての何らかの考えがこの記事を与えます 。 この記事は少し時代遅れですが、今ではギャップはさらに大きくなります。
• 4番目の警告レベルをオンにしてコンパイラーにヘルプを求めることは、常に可能ではありません。 ただし、4番目と3番目のレベルの警告では、64ビットエラーに関連する警告（アナライザーとコンパイラーを使用）は2つしか表示されません。 あまり印象的な結果ではありません。
• 「/ Wall」フラグを設定すると、プロジェクトに関連しない警告が大量に表示されます。 実際には、「/ Wall」の使用は困難です。 いくつかの警告を個別にオンにすることもできますが、それでも多くの過剰なノイズが残っています。

上記からわかるように、Microsoft Visual Studio 2013で検出された64ビットエラーを検出するには、ある程度の作業を行う必要があります。 それがどれだけ増加するか想像してみてください、それが本当の、本当に大きなプロジェクトであるなら。



PVS-Studioはどうですか？ 数回のマウスクリックで診断を実行し、64ビットエラーと必要な警告のフィルタリングを設定すると、結果が得られます。

おわりに

64ビットアーキテクチャへのアプリケーションの移植には多くの困難が伴うことを示すことができたと思います。 この記事で説明したようなエラーは簡単に発生しますが、見つけるのは非常に困難です。 これに、このようなエラーのすべてがMicrosoft Visual Studio 2013によって検出されるわけではないという事実と、特定の作業を行うために必要なエラーを見つけるために追加します。 同時に、 PVS-Studio静的アナライザーはタスクに対処し、適切な結果を示しました。 さらに、エラーの検索とフィルタリングのプロセスはより簡単で便利です。 このようなツールを使用しない本当に大きなプロジェクトでは、タイトにする必要があることを認めなければなりません。そのため、このような場合には優れた静的アナライザーが必要になります。



64ビットアプリケーションを開発していますか？ PVS-Studioトライアルをダウンロードし、プロジェクトをチェックして、最初のレベルの64ビットメッセージの数を確認します。 それでもいくつか表示される場合は、それらを修正して、この世界を少し良くしてください。

追加資料

約束どおり、64ビットエラーのトピックに関する追加資料のリストを示します。

• 用語。 64ビットエラー ;
• アンドレイ・カルポフ。 実際のプログラムでの64ビットエラーの例のコレクション 。
• アンドレイ・カルポフ。 C ++ 11および64ビットエラー 。
• アンドレイ・カルポフ、エフゲニー・リズコフ。 64ビットC / C ++アプリケーションの開発のためのレッスン 。

この記事は英語です。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Sergey Vasiliev。 2015年の64ビットコード：考えられる問題の診断の新機能 。