↕️ 🙎🏻 🥜 PVS-StudioはCERNの救助に駆けつけます：Geant4プロジェクトをチェックします 🍽️ 👩🏽‍💻 👩🏿‍🔧

Geant4プロジェクトは引き続き開発されているため、PVS-Studio静的コードアナライザーを使用して再度確認するのは興味深いことです。今回は、バージョン10.2がテストされます（以前の検証はバージョン10.0-betaでした）。

はじめに

Geant4ツールキットはCERNで開発され、モンテカルロ法を使用して物質を通過する粒子の挙動をモデリングおよび研究するように設計されています。プロジェクトの初期バージョンはFortranで作成され、バージョン4以降、プロジェクトはオブジェクト指向C ++言語に完全に翻訳されました。

プロジェクトの詳細については、プロジェクトの公式ウェブサイトhttp://geant4.orgをご覧ください。

Geant4プロジェクトは既に数回テストされており、他の記事ではその結果について説明しています。バージョン9.4の検証は、記事「 Copy-Paste and Muons 」にあり、バージョン10.0-betaの検証は、記事「 Continuation of Geant4 Validation 」にあります。

前回のチェック以降、Geant4.10.2の新しいバージョンがリリースされました。それ以来PVS-Studioも更新されており、検証にはアナライザーバージョン6.05が使用されました。

このプロジェクトでは、条件と比較に関連する非常に多くのエラーに遭遇しました。論理エラーは、多くの場合、将来の改訂のためにコードを残したり、コードの移行を制御する以前の部分を削除して不正確な変更を行ったりするときに発生します。しかし、単純なタイプミスや考え抜かれた表現も、エラーや過剰なコードにつながる可能性があります。

パイカンシー

私が理解しているように、Geant4プロジェクトがCoverity静的アナライザーによって定期的にチェックされるという事実によって、プロジェクトの次の検証に対する追加の海賊行為が与えられます。これは、次の形式のコード内の複数のリリースノートとコメントによって証明されます。

// Private copy constructor and assigment operator - copying and // assignment not allowed. Keeps Coverity happy.

Coverityアナライザーはマーケットリーダーであると考えられているため、何かを見つけた後は良い成果です。それでも、PVS-Studioは多くの興味深いエラーを発見しました。これは、PVS-Studioが成熟した強力な製品になったということです。

「その他」がありません

 G4double G4EmBiasingManager::ApplySecondaryBiasing(....) { .... if(0 == nsplit) { .... } if(1 == nsplit) { //<- .... } else { .... } .... }

V646アプリケーションのロジックの検査を検討してください。「else」キーワードが欠落している可能性があります。 g4embiasingmanager.cc 299

これは、 ifを使用して単一の変数で複数の値をチェックする際によくある間違いの1つです。もちろん、これは単に誤ったフォーマット設定である可能性がありますが、この例では、アナライザーがエラーを示している可能性が高いです。

コードをコピーした結果、elseという単語は忘れられました。この場合、余分なコードの実行につながります。たとえば、値はゼロになり、アドバイスブロックのコードが実行されますが、エラーのため、 elseブロックのコードも一致を確認した後に実行されます。エラーを修正するには、 if条件（1 == nsplit）の前に見つからないelseを追加します。

考えられるエラーの誤った処理

 void G4GenericPolycone::Create( .... ) { .... G4double rzArea = rz->Area(); if (rzArea < -kCarTolerance) rz->ReverseOrder(); else if (rzArea < -kCarTolerance) //<- { .... G4Exception("G4GenericPolycone::Create()", "GeomSolids0002", FatalErrorInArgument, message); } .... }

V517 「if（A）{...} else if（A）{...}」パターンの使用が検出されました。論理エラーが存在する可能性があります。行を確認：102、105。g4genericpolycone.cc 102

コードの目的についてのみ推測できます。このフラグメントがエラーメッセージのインターセプトと生成を担当している可能性が非常に高いですが、誤った状態の結果として、エラーメッセージはありません。そして、プログラムがどのように動作するかは不明です。エラーが別の場所のハンドラーによってインターセプトされる可能性があります。または、プログラムがエラーなしで実行を継続し、誤った結果を生成する可能性があります。エラーが何であるかを正確に言うことは非常に困難です。なぜなら、それは条件式のいずれかまたは余分なelseにある可能性があるからです。しかし、フォーマットによって判断すると、条件の両方のブロックが正しいと安全に想定でき、修正のためには、2番目の条件ブロックの前にelseを削除するだけで十分です。

コードのコピーのおかげで、同じエラーが伝播され、プロジェクトのさらに3つの場所で発見されました。

V517「if（A）{...} else if（A）{...}」パターンの使用が検出されました。論理エラーが存在する可能性があります。行を確認：193、196。g4polycone.cc 193
V517「if（A）{...} else if（A）{...}」パターンの使用が検出されました。論理エラーが存在する可能性があります。行を確認：219、222。g4polyhedra.cc 219
V517「if（A）{...} else if（A）{...}」パターンの使用が検出されました。論理エラーが存在する可能性があります。行を確認：207、211。g4persistencycentermessenger.cc 207

NULLポインター逆参照

 G4double * theShells; G4double * theGammas; void G4ParticleHPPhotonDist::InitAngular(....) { .... if ( theGammas != NULL ) { for ( i = 0 ; i < nDiscrete ; i++ ) { vct_gammas_par.push_back( theGammas[ i ] ); vct_shells_par.push_back( theShells[ i ] ); .... } } if ( theGammas == NULL ) theGammas = new G4double[nDiscrete2]; if ( theShells == NULL ) theShells = new G4double[nDiscrete2]; .... }

V595 nulltherに対して検証される前に、「theShells」ポインターが使用されました。行を確認してください：147、156。g4particlehpphotondist.cc 147

ポインターを操作する際のエラーは、プログラムで頻繁に検出されます。ここでは、2つのオブジェクトの同時作業が発生し、そのうちの1つだけが正しいかどうかがチェックされます。このようなエラーは長い間気付かれない場合がありますが、 Shellsオブジェクトへのポインターがnullになった場合、プログラムの未定義の動作につながります。エラーを修正するには、次のように条件を変更する必要があります。

 if ( theGammas != NULL && theShells != NULL) ....

ポインターチェックのない別のフラグメント：

V595 nullptrに対して検証される前に、「fCurrentProcess」ポインターが使用されました。行をチェックしてください：303、307。g4steppingmanager2.cc 303

NULLポインターを使用する

 G4hhElastic::G4hhElastic(....) : G4HadronElastic("HadrHadrElastic") { .... fTarget = target; // later vmg fProjectile = projectile; .... fTarget = G4Proton::Proton(); // later vmg fProjectile = 0; //<- fMassTarg = fTarget->GetPDGMass(); fMassProj = fProjectile->GetPDGMass(); //<- .... }

V522 nullポインター「fProjectile」の逆参照が行われる場合があります。 g4hhelastic.cc 184

このスニペットは前のものと似ています。ただし、ここではポインターに明示的にnull値が割り当てられ、その後、変数は他の変数を初期化するために使用されます。おそらく、最初の割り当ての変数の値を使用することになっていたのに、2番目の割り当ては単に不要です。おそらく、別の変数に0を割り当てたいと思うでしょう。この割り当ての本当の理由は、プロジェクト開発者のみが知っています。いずれにせよ、そのような初期化は正しくなく、そのようなコードは注意する価値があります。

ビットごとの無効な操作

 #define dependentAxis 1 #define allowByRegion 2 static enum xDataTOM_interpolationFlag xDataTOM_interpolation_getFromString( .... ) { .... if( flag | allowByRegion ) {....} //<- if( flag | dependentAxis ) {....} //<- .... }

V617状態の検査を検討してください。「|」の「2」引数ビット単位演算にゼロ以外の値が含まれています。 xdatatom_interpolation.cc 85
V617状態の検査を検討してください。「|」の「1」引数ビット単位演算にゼロ以外の値が含まれています。 xdatatom_interpolation.cc 88

アナライザーは、関数の隣接する2行ですぐに警告を出しました。条件内では、ビット単位のORがゼロ以外の定数で発生します。このような式の結果は常にゼロ以外の値になり、プログラムのロジックが不正になります。ほとんどの場合、このようなエラーはタイプミスの結果として発生します。また、条件では、ビット単位のORの代わりに、別のビット単位の演算を使用する必要があります。この場合、私はビット単位のIを意味したと推測できます。修正されたコードは次のようになります。

 if( flag & allowByRegion ) {....} if( flag & dependentAxis ) {....}

追加の割り当て

 G4ThreeVector G4GenericTrap::SurfaceNormal(....) const { .... if ( noSurfaces == 0 ) { .... sumnorm=apprnorm; } else if ( noSurfaces == 1 ) { sumnorm = sumnorm; } //<- else { sumnorm = sumnorm.unit(); } .... }

V570 「sumnorm」変数はそれ自体に割り当てられます。 g4generictrap.cc 515

このフラグメントでは、過剰条件分岐で構成される論理エラーが表示されます。プログラマーがしたかったオプションの1つ：1つと等しいかどうかをチェックするとき、変数には別の変数が割り当てられているはずで、その名前はsumnormに似ています。 しかし、コードのチェックされた部分でそのような変数が検出されなかったため、私はこれが単なる追加のチェックであると思い込んでいます。エラーを修正するには、次のように条件を単純化することを提案します。

 if ( noSurfaces == 0 ) { .... sumnorm=apprnorm; } else if ( noSurfaces != 1 ) { sumnorm = sumnorm.unit(); }

別の不審な場所。

 void G4UImanager::StoreHistory(G4bool historySwitch,....) { if(historySwitch) { if(saveHistory) { historyFile.close(); } historyFile.open((char*)fileName); saveHistory = true; } else { historyFile.close(); saveHistory = false; } saveHistory = historySwitch; }

V519 「saveHistory」変数には連続して2回値が割り当てられます。おそらくこれは間違いです。チェック行：541、543。g4uimanager.cc 543

論理エラーもあります。関数内のコードは、 historySwitchの値に応じて、 saveHistoryフラグの値を変更し、ファイル操作を実行します。その結果はフラグによって報告されます。ただし、すべての操作が完了すると、 saveHistory変数にhistorySwitchの値が割り当てられます。これは奇妙な操作です。条件内の値はすでに確立されており、それを台無しにするだけだからです。ほとんどの場合、最後の割り当ては不要であり、削除する必要があります。

他にも同様のエラーがあります：

V519「lvl」変数には連続して2回値が割り当てられます。おそらくこれは間違いです。行を確認してください：277、283。g4iontable.cc 283

単一の式の複数検証

 bool parse(....) { .... if( (word0=="line_pattern") || (word0=="line_pattern") ) { .... } .... }

V501 「||」の左と右に同一の副次式「（word0 == "line_pattern"）」があります演算子。 style_parser 1172

ほとんどの場合、同じ条件内で同じ型の変数セットをチェックし、Copy-Pasteメソッドを使用して生成すると、このようなエラーが発生します。

この例には、エラーが明示的に表示されるかなり小さなコードが含まれています。この場合、それは単なるタイプミスであり、コードのコピーが原因である可能性が高いです。しかし、これは定期的なチェック中に簡単に検出できるという意味ではありません。この状態は、さまざまなチェックの長いツリーから取得されました。アナライザーがコードのリファクタリング時のエラーを識別し、防止するのに役立つのは、まさにそのような構造です。

これがエラーではない場合でも、二重チェックがこのコードをサポートする人を煩わさないように、コードを修正する必要があります。

プロジェクトの他の場所でも同様の断片が見つかりました。

V501「||」の左と右に同一のサブ式があります演算子：ITTU->サイズ（）！= np || ITTU->サイズ（）！= Np g4peneloperayleighmodel.cc 11563
V501「||」の左と右に同一の副次式「（ptwXY1-> Interpolation == ptwXY_interpolationFlat）」があります。演算子。 ptwxy_binaryoperators.cc 301

ずさんなリファクタリング

 G4ReactionProduct * G4ParticleHPLabAngularEnergy::Sample(....) { .... //if ( it == 0 || it == nEnergies-1 ) if ( it == 0 ) { if(it==0) .... .... } .... }

V571定期的なチェック。「if（it == 0）」条件は、123行目で既に検証されています。g4particlehplabangularenergy.cc 125

コードのリファクタリングの過程で、不完全なフラグメントが残る場合があります。これは例で起こりました。古い条件はコメントアウトされ、新しい条件は内部の追加チェックに正確に対応し始めました。エラーを修正するには、コードブロックの修正を熟考するか、条件内の追加チェックを削除することをお勧めします。

同様の欠陥を持つフラグメント：

V571定期的なチェック。「if（proj_momentum> = 10.）」条件は、809行目ですでに検証されています。g4componentgghadronnucleusxsc.cc 815
V571定期的なチェック。「if（proj_momentum> = 10.）」条件は、869行目で既に検証されています。g4componentgghadronnucleusxsc.cc 875
V571定期的なチェック。「if（proj_momentum> = 10.）」条件は、568行目で既に検証されています。g4componentggnuclnuclxsc.cc 574
V571定期的なチェック。「if（proj_momentum> = 10.）」条件は、1868行目で既に検証されています。g4nuclnucldiffuseelastic.cc 1875

検証済みの表現

 void GFlashHitMaker::make(....) { .... if( gflashSensitive ) { gflashSensitive->Hit(&theSpot); } else if ( (!gflashSensitive ) && ( pSensitive ) && (....) ){....} .... }

V560条件式の一部は常に真です：（！GflashSensitive）。 gflashhitmaker.cc 102

上記のブロックでは、 elseセクションの条件は冗長です。したがって、 elseブロックに入るための条件はgflashSensitive変数の偽の値であり、2回目にチェックする必要はありません。

別の同様の場所：

 void UseWorkArea( T* newOffset ) { .... if( offset && offset!=newOffset ) { if( newOffset != offset ) {....} else {....} } .... }

V571定期的なチェック。 'newOffset！= Offset'条件は、154行目で既に検証されています。g4geomsplitter.hh 156

同じ変数が条件の内部ブロックで再チェックされます。これは条件の内部ブロックに入るための条件であったため、このチェックは常に肯定的な結果をもたらします。その結果、内部のelseブロックのコードは実行されません。

コードをコピーした結果、プロジェクトの他の場所にも同じ追加チェックが存在します。ああ、このコピーペースト：

V571定期的なチェック。 'newOffset！= Offset'条件は、113行目で既に検証されています。g4pdefsplitter.hh 115
V571定期的なチェック。 'newOffset！= Offset'条件は、141行目で既に検証されています。g4vuplsplitter.hh 143

役に立たない状態

 void G4XXXStoredViewer::DrawView() { .... if (kernelVisitWasNeeded) { DrawFromStore(); } else { DrawFromStore(); } .... }

V523 「then」ステートメントは「else」ステートメントと同等です。 g4xxxstoredviewer.cc 85

条件の2つのブランチ内のコードは同一であり、同じコードが独立して実行されるため、条件自体が役に立たなくなります。このようなアナライザーメッセージは、名前が似ているさまざまな定数または関数をコピーするときに、不完全なコードまたはタイプミスを示すことがあります。この場合、このブロックが作成された理由はわかりませんが、明確に確定する必要があります。

同様のフラグメントがプロジェクトの別の場所にあります。

V523「then」ステートメントは「else」ステートメントと同等です。 g4xxxsgviewer.cc 84

冗長条件

 Void G4VTwistSurface::CurrentStatus::ResetfDone(....) { if (validate == fLastValidate && p && *p == fLastp) { if (!v || (v && *v == fLastv)) return; } .... }

V728過剰なチェックを簡素化できます。「||」演算子は、反対の式「！v」と「v」に囲まれています。 g4vtwistsurface.cc 1198

このフラグメントはエラーではありません。ただし、条件は次のように簡略化できます。

 if (!v || *v == fLastv) return;

同様のフラグメントは他の場所にあります。

V728過剰なチェックを簡素化できます。「||」演算子は反対の式「！a_cut」と「a_cut」に囲まれています。配列168
V728過剰なチェックを簡素化できます。「||」演算子は反対の式「！a_cut」と「a_cut」に囲まれています。配列180
V728過剰なチェックを簡素化できます。「||」演算子は反対の式「！a_cut」と「a_cut」に囲まれています。配列240
V728過剰なチェックを簡素化できます。「||」演算子は反対の式「！a_cut」と「a_cut」に囲まれています。配列287
V728過剰なチェックを簡素化できます。「||」演算子は、反対の式「p == 0」および「p！= 0」に囲まれています。 g4emmodelactivator.cc 216

無効なコンストラクター呼び出し

 class G4PhysicsModelCatalog { private: .... G4PhysicsModelCatalog(); .... static modelCatalog* catalog; .... }; G4PhysicsModelCatalog::G4PhysicsModelCatalog() { if(!catalog) { static modelCatalog catal; catalog = &catal; } } G4int G4PhysicsModelCatalog::Register(const G4String& name) { G4PhysicsModelCatalog(); .... }

V603オブジェクトは作成されましたが、使用されていません。コンストラクターを呼び出す場合は、「this-> G4PhysicsModelCatalog :: G4PhysicsModelCatalog（....）」を使用する必要があります。 g4physicsmodelcatalog.cc 51

現在のオブジェクトにアクセスする代わりに、新しい一時オブジェクトが作成され、すぐに破棄されます。その結果、オブジェクトフィールドは初期化されません。コンストラクタの外部でフィールドの初期化を使用する必要がある場合は、このために別の関数を作成して呼び出すことをお勧めします。ただし、コンストラクタを正確に呼び出す場合は、 thisという単語を使用してコンストラクタを参照する必要があります。 C ++ 11を使用する場合、最も美しい解決策は委任コンストラクターを使用することです。このようなエラーについては、本書でさらに詳しく説明し、修正方法を説明します（セクション19「別のコンストラクタから適切に呼び出す方法」を参照）。

初期化のタイプミス

 static const G4String name[numberOfMolecula] = { .... "(CH_3)_2S", "N_2O", "C_5H_10O" "C_8H_6", "(CH_2)_N", .... };

V653 2つの部分で構成される疑わしい文字列は、配列の初期化に使用されます。コンマが欠落している可能性があります。このリテラルの検査を検討してください： "C_5H_10O" "C_8H_6"。 g4hparametrisedlossmodel.cc 324

定数を使用した配列の初期化に誤りがありました。タイプミスの結果、コンマが省略されました。ここにはいくつかの問題があります：

2つの文字列定数が1つに連結されます。そして、式「C_5H_10OC_8H_6」の1つとして取得します。前例のない種類のアルコール。
インデックスで配列を見ると、必要な間違った式の名前を取得できます。
そして最後-配列の境界を越えることが可能です。

忘れられた投げ

 class G4HadronicException : public std::exception {....} void G4CrossSectionDataStore::ActivateFastPath( ....) { .... if ( requests.insert( { key , min_cutoff } ).second ) { .... G4HadronicException(__FILE__,__LINE__,msg.str()); } }

V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4crosssectiondatastore.cc 542

関数コードの大部分は、例外をスローするメッセージの生成に関係しています。ただし、 throwが欠落しているため、未使用の例外がスローされます。そして、プログラムは引き続き動作し、未定義のプログラムの動作や誤った計算につながる可能性があります。

このエラーはプロジェクトの他の場所で繰り返されました。

V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4generalphasespacedecay.hh 126
V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4particlehpthermalscattering.cc 515
V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4particlehpthermalscattering.cc 574
V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4particlehpthermalscattering.cc 585
V596オブジェクトは作成されましたが、使用されていません。「throw」キーワードが欠落している可能性があります。throwG4HadronicException（FOO）; g4particlehpthermalscattering.cc 687

出力エラー

 bool G4GMocrenIO::storeData2() { .... ofile.write("GRAPE ", 8); .... }

V666関数 'write'の2番目の引数を調べることを検討してください。値が、最初の引数で渡された文字列の長さと一致しない可能性があります。 g4gmocrenio.cc 1351

上記のエラーは、文字列の実際の長さと、関数内の長さを設定する引数の不一致に関連しています。この場合、スペースを含む特定のインデントが形成されたためにエラーが発生し、一見すると実際にいくつあるかが見えません。おそらくこれが、このエラーに十分な注意が払われておらず、最初のチェック時からプロジェクトに存在している理由です。このエラーは、V666診断サンプルデータベースに含まれていました。

おわりに

おそらく、これらのエラーのすべてが危険なわけではありませんが、一見取るに足りないエラーの多くは将来、より深刻な結果につながる可能性があります。したがって、プロジェクトを定期的にチェックして、重大な結果を招く前に、初期段階でエラーを特定する必要があります。アナライザーは、最もキャッチーなエラーを見つけて修正するだけでなく、エラーになる前にプロジェクト内の危険な場所を見つけるのにも役立ちます。プロジェクトでPVS-Studioアナライザーをダウンロードして試すことをお勧めします。

PVS-StudioはCERNの救助に駆けつけます：Geant4プロジェクトをチェックします