PVS-Studio：CoreCLRからの25の疑わしいコードフラグメント

Microsoftは、.NET Coreの重要な要素であるCoreCLRエンジンのソースコードを公開しました。 もちろん、このニュースは私たちの注意を引くことができませんでした。 実際、プロジェクトの聴衆が多いほど、発見された疑わしい場所がより警戒されます。 主要なプロジェクトのように、Microsoftの著者であるにもかかわらず、見たり考えたりすることがあります。

はじめに

CoreCLRは、ガベージコレクションや最終的なマシンコードへのコンパイルなどの機能を実行する.NET Coreランタイムです。 .Net Coreは.Netのモジュラー実装であり、膨大な数のシナリオのベースとして使用できます。

ソースコードは最近GitHubで利用可能になり、 PVS-Studio 5.23を使用してテストされました。 私と同じように、Microsoft Visual Studio Community Editionを使用して誰でも完全な検証ログを取得できます。その出力もMicrosoftからの最近のニュースでした。

タイプミス

伝統的に、私はタイプミスのような場所から始めます。 条件式では、変数、定数、マクロ、または構造/クラスのフィールドが繰り返されます。 エラーの存在は議論の問題ですが、そのような場所は発見されており、疑わしいようです。

V501 「||」の左側と右側に同一のサブ式「tree-> gtOper == GT_CLS_VAR」があります 演算子。 ClrJit lsra.cpp 3140

// register variable GTNODE(GT_REG_VAR , "regVar" ,0,GTK_LEAF|GTK_LOCAL) // static data member GTNODE(GT_CLS_VAR , "clsVar" ,0,GTK_LEAF) // static data member address GTNODE(GT_CLS_VAR_ADDR , "&clsVar" ,0,GTK_LEAF) .... void LinearScan::buildRefPositionsForNode(GenTree *tree, ....) { .... if ((tree->gtOper == GT_CLS_VAR || tree->gtOper == GT_CLS_VAR) && i == 1) { registerType = TYP_PTR; currCandidates = allRegs(TYP_PTR); } .... } 

「GenTree」構造のフィールド名は「tree-> gtType」と似ていますが、「tree-> gtOper」とは異なるタイプです。 ここでのポイントはコピーされた定数にあると思います。 つまり、GT_CLS_VARに加えて、別の定数を式で使用する必要があります。

V501 「|」の左と右に同じ副次式「DECODE_PSP_SYM」があります 演算子。 daccess 264

 enum GcInfoDecoderFlags { DECODE_SECURITY_OBJECT = 0x01, DECODE_CODE_LENGTH = 0x02, DECODE_VARARG = 0x04, DECODE_INTERRUPTIBILITY = 0x08, DECODE_GC_LIFETIMES = 0x10, DECODE_NO_VALIDATION = 0x20, DECODE_PSP_SYM = 0x40, DECODE_GENERICS_INST_CONTEXT = 0x80, DECODE_GS_COOKIE = 0x100, DECODE_FOR_RANGES_CALLBACK = 0x200, DECODE_PROLOG_LENGTH = 0x400, DECODE_EDIT_AND_CONTINUE = 0x800, }; size_t GCDump::DumpGCTable(PTR_CBYTE table, ....) { GcInfoDecoder hdrdecoder(table, (GcInfoDecoderFlags)( DECODE_SECURITY_OBJECT | DECODE_GS_COOKIE | DECODE_CODE_LENGTH | DECODE_PSP_SYM //<==1 | DECODE_VARARG | DECODE_PSP_SYM //<==1 | DECODE_GENERICS_INST_CONTEXT //<==2 | DECODE_GC_LIFETIMES | DECODE_GENERICS_INST_CONTEXT //<==2 | DECODE_PROLOG_LENGTH), 0); .... } 

「GcInfoDecoderFlags」列挙には条件で使用されない他の定数がありますが、2つの繰り返し定数もあります。

同様の場所：

• V501「==」演算子の左側と右側に同一の副次式「varLoc1.vlStk2.vls2BaseReg」があります。 cee_wks util.cpp 657
• V501「==」演算子の左側と右側には、同一のサブ式「varLoc1.vlStk2.vls2Offset」があります。 cee_wks util.cpp 658
• V501「==」演算子の左側と右側には、同一のサブ式「varLoc1.vlFPstk.vlfReg」があります。 cee_wks util.cpp 661

V700 「T foo = foo = ...」式の検査を検討してください。 変数がそれ自体で初期化されるのは奇妙です。 cee_wks zapsig.cpp 172

 BOOL ZapSig::GetSignatureForTypeHandle(....) { .... CorElementType elemType = elemType = TryEncodeUsingShortcut(pMT); .... } 

これは単なる不必要な割り当てのように見えますが、コードをコピーして名前を変更するのを忘れると、このようなエラーがよく発生します。 いずれにしても、この形式では、コードは無意味です。

V523 「then」ステートメントは「else」ステートメントと同等です。 cee_wks threadsuspend.cpp 2468

 enum __MIDL___MIDL_itf_mscoree_0000_0004_0001 { OPR_ThreadAbort = 0, OPR_ThreadRudeAbortInNonCriticalRegion = .... , OPR_ThreadRudeAbortInCriticalRegion = ....) , OPR_AppDomainUnload = .... , OPR_AppDomainRudeUnload = ( OPR_AppDomainUnload + 1 ) , OPR_ProcessExit = ( OPR_AppDomainRudeUnload + 1 ) , OPR_FinalizerRun = ( OPR_ProcessExit + 1 ) , MaxClrOperation = ( OPR_FinalizerRun + 1 ) } EClrOperation; void Thread::SetRudeAbortEndTimeFromEEPolicy() { LIMITED_METHOD_CONTRACT; DWORD timeout; if (HasLockInCurrentDomain()) { timeout = GetEEPolicy()-> GetTimeout(OPR_ThreadRudeAbortInCriticalRegion); //<== } else { timeout = GetEEPolicy()-> GetTimeout(OPR_ThreadRudeAbortInCriticalRegion); //<== } .... } 

この診断は、if / else構造内で同じブロックを見つけます。 そして、ここでも、定数にタイプミスの疑いがあります。 最初のケースでは、ある意味で、「OPR_ThreadRudeAbortInNonCriticalRegion」が適切です。

同様の場所：

• V523「then」ステートメントは「else」ステートメントと同等です。 ClrJit instr.cpp 3427
• V523「then」ステートメントは「else」ステートメントと同等です。 ClrJit flowgraph.cpp 18815
• V523「then」ステートメントは「else」ステートメントと同等です。 daccess dacdbiimpl.cpp 6374

コンストラクター初期化リスト

V670初期化されていないクラスメンバー 'gcInfo'は、 'regSet'メンバーを初期化するために使用されます。 メンバーは、クラス内の宣言の順序で初期化されることに注意してください。 ClrJit codegencommon.cpp 92

 CodeGenInterface *getCodeGenerator(Compiler *comp); class CodeGenInterface { friend class emitter; public: .... RegSet regSet; //<=== line 91 .... public: GCInfo gcInfo; //<=== line 322 .... }; // CodeGen constructor CodeGenInterface::CodeGenInterface(Compiler* theCompiler) : compiler(theCompiler), gcInfo(theCompiler), regSet(theCompiler, gcInfo) { } 

標準に従って、コンストラクター内のクラスメンバーの初期化の順序は、クラス内の宣言の順序で発生します。 エラーを修正するには、クラス「gcInfo」のメンバーの宣言を「regSet」の宣言の上に移動する必要があります。

偽だが有用な警告

V705「else」ブロックが忘れられているかコメントアウトされている可能性があり、そのためプログラムの動作ロジックが変更されています。 daccess daccess.cpp 2979

 HRESULT Initialize() { if (hdr.dwSig == sig) { m_rw = eRO; m_MiniMetaDataBuffSizeMax = hdr.dwTotalSize; hr = S_OK; } else // when the DAC initializes this for the case where the target is // (a) a live process, or (b) a full dump, buff will point to a // zero initialized memory region (allocated w/ VirtualAlloc) if (hdr.dwSig == 0 && hdr.dwTotalSize == 0 && hdr.dwCntStreams == 0) { hr = S_OK; } // otherwise we may have some memory corruption. treat this as // a liveprocess/full dump else { hr = S_FALSE; } .... } 

アナライザーは、コード内の疑わしい場所を検出しました。 ここでは、コードがコメント化されており、すべてが正常であることがわかります。 しかし、このタイプのエラーは、「else」の後のコードがコメント化され、それに続くステートメントが条件の一部になる場合に非常に一般的です。 この例では、エラーはありませんが、将来この場所を編集する場合はかなり許容できます。

64ビットエラー

V673 「0xefefefef << 28」式は1080581331517177856に評価されます。値を保存するには60ビットが必要ですが、式は「32」ビットのみを保持できる「符号なし」タイプに評価されます。 cee_dac _dac object.inl 95

 inline void Object::EnumMemoryRegions(void) { .... SIZE_T size = sizeof(ObjHeader) + sizeof(Object); .... size |= 0xefefefef << 28; .... } 

「64ビットエラー」という用語については、 こちらをご覧ください 。 この例では、シフト後、32ビットプログラムでは「size | = 0xf0000000」、64ビットプログラムでは「size | = 0x00000000f0000000」の演算が実行されます。 ほとんどの場合、64ビットプログラムでは、「サイズ| = 0x0efefefef0000000」の計算を計画していました。 しかし、数字の古い部分はどこで失われますか？

数値「0xefefefef」は「unsigned」タイプです。これは「int」タイプに適合しないためです。 32ビットの数値がシフトされ、その結果、符号なし型の0xf0000000が取得されます。 さらに、この符号なしの数値はSIZE_Tに拡張され、0x00000000f0000000が得られます。

正しく動作させるには、まず明示的な型変換を実行する必要があります。 正しいコードの例：

 inline void Object::EnumMemoryRegions(void) { .... SIZE_T size = sizeof(ObjHeader) + sizeof(Object); .... size |= SIZE_T(0xefefefef) << 28; .... } 

このような別の場所：

• V673「0xefefefef << 28」式は1080581331517177856に評価されます。値を保存するには60ビットが必要ですが、式は「32」ビットのみを保持できる「符号なし」タイプに評価されます。 cee_dac dynamicmethod.cpp 807

廃止コード

条件は、文字通り互いに矛盾するように記述される場合があります。

V637反対の2つの条件が発生しました。 2番目の条件は常にfalseです。 行を確認してください：31825、31827。cee_wks gc.cpp 31825

 void gc_heap::verify_heap (BOOL begin_gc_p) { .... if (brick_table [curr_brick] < 0) { if (brick_table [curr_brick] == 0) { dprintf(3, ("curr_brick %Ix for object %Ix set to 0", curr_brick, (size_t)curr_object)); FATAL_GC_ERROR(); } .... } .... } 

制御を得ることはないが、次の例ほど重要ではないコード：

V517 「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 行を確認してください：2353、2391。utilcode util.cpp 2353

 void PutIA64Imm22(UINT64 * pBundle, UINT32 slot, INT32 imm22) { if (slot == 0) { const UINT64 mask0 = UI64(0xFFFFFC000603FFFF); /* Clear all bits used as part of the imm22 */ pBundle[0] &= mask0; UINT64 temp0; temp0 = (UINT64) (imm22 & 0x200000) << 20; // 1 s temp0 |= (UINT64) (imm22 & 0x1F0000) << 11; // 5 imm5c temp0 |= (UINT64) (imm22 & 0x00FF80) << 25; // 9 imm9d temp0 |= (UINT64) (imm22 & 0x00007F) << 18; // 7 imm7b /* Or in the new bits used in the imm22 */ pBundle[0] |= temp0; } else if (slot == 1) { .... } else if (slot == 0) //<== { const UINT64 mask1 = UI64(0xF000180FFFFFFFFF); /* Clear all bits used as part of the imm22 */ pBundle[1] &= mask1; UINT64 temp1; temp1 = (UINT64) (imm22 & 0x200000) << 37; // 1 s temp1 |= (UINT64) (imm22 & 0x1F0000) << 32; // 5 imm5c temp1 |= (UINT64) (imm22 & 0x00FF80) << 43; // 9 imm9d temp1 |= (UINT64) (imm22 & 0x00007F) << 36; // 7 imm7b /* Or in the new bits used in the imm22 */ pBundle[1] |= temp1; } FlushInstructionCache(GetCurrentProcess(),pBundle,16); } 

おそらく、非常に重要なコードは、条件付きステートメントのカスケードのエラーのために制御されません。

より不審な場所：

• V637反対の2つの条件が発生しました。 2番目の条件は常にfalseです。 行を確認してください：2898、2900。daccess nidump.cpp 2898
• V637反対の2つの条件が発生しました。 2番目の条件は常にfalseです。 行を確認してください：337、339。utilcode prettyprintsig.cpp 337
• V637反対の2つの条件が発生しました。 2番目の条件は常にfalseです。 行を確認してください：774、776。utilcode prettyprintsig.cpp 774

未定義の動作

V610未定義の動作。 シフト演算子「<<」を確認してください。 左のオペランド '-1'は負です。 bcltype metamodel.h 532

 inline static mdToken decodeToken(....) { //<TODO>@FUTURE: make compile-time calculation</TODO> ULONG32 ix = (ULONG32)(val & ~(-1 << m_cb[cTokens])); if (ix >= cTokens) return rTokens[0]; return TokenFromRid(val >> m_cb[cTokens], rTokens[ix]); } 

アナライザーは、未定義の動作につながる負の数値シフト操作を検出しました。

V610未定義の動作。 シフト演算子「<<」を確認してください。 左のオペランド '（〜0）'は負です。 cee_dac decodemd.cpp 456

 #define bits_generation 2 #define generation_mask (~(~0 << bits_generation)) #define MASK(len) (~((~0)<<len)) #define MASK64(len) ((~((~((unsigned __int64)0))<<len))) void Encoder::Add(unsigned value, unsigned length) { .... value = (value & MASK(length)); .... } 

V610アナライザーからのメッセージのおかげで、いくつかの誤ったマクロが見つかりました。 '〜0'は、int型の符号付き負の数にキャストされ、その後シフトが実行されます。 マクロの1つと同様に、符号なしへの明示的な変換を実行する必要があります。

 #define bits_generation 2 #define generation_mask (~(~((unsigned int)0) << bits_generation)) #define MASK(len) (~((~((unsigned int)0))<<len)) #define MASK64(len) ((~((~((unsigned __int64)0))<<len))) 

無効なサイズ（xx）

V579 DacReadAll関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 3番目の引数を調べます。 daccess dacimpl.h 1688

 template<class T> inline bool MisalignedRead(CORDB_ADDRESS addr, T *t) { return SUCCEEDED(DacReadAll(TO_TADDR(addr), t, sizeof(t), false)); } 

これは、常にポインターのサイズをとる小さな関数です。 ほとんどの場合、「sizeof（* t）」、または「sizeof（T）」を記述したいと考えていました。

別の実例：

V579読み取り関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 3番目の引数を調べます。 util.cpp 4943

 HRESULT GetMTOfObject(TADDR obj, TADDR *mt) { if (!mt) return E_POINTER; HRESULT hr = rvCache->Read(obj, mt, sizeof(mt), NULL); if (SUCCEEDED(hr)) *mt &= ~3; return hr; } 

MemFAILファミリーの機能

memXXX関数を使用すると、さまざまなエラーが発生する可能性があります。 アナライザーでそのような場所を検索するには、いくつかの診断ルールがあります。

V512 「memset」関数の呼び出しにより、バッファー「pAddExpression」のアンダーフローが発生します。 sos strike.cpp 11973

 DECLARE_API(Watch) { .... if(addExpression.data != NULL || aExpression.data != NULL) { WCHAR pAddExpression[MAX_EXPRESSION]; memset(pAddExpression, 0, MAX_EXPRESSION); swprintf_s(pAddExpression, MAX_EXPRESSION, L"%S", ....); Status = g_watchCmd.Add(pAddExpression); } .... } 

サイズタイプの調整を忘れた場合のよくある間違い：

 WCHAR pAddExpression[MAX_EXPRESSION]; memset(pAddExpression, 0, sizeof(WCHAR)*MAX_EXPRESSION); 

さらにいくつかのそのような場所：

• V512「memset」関数の呼び出しにより、バッファー「pSaveName」のアンダーフローが発生します。 sos strike.cpp 11997
• V512「memset」関数の呼び出しにより、バッファー「pOldName」のアンダーフローが発生します。 sos strike.cpp 12013
• V512「memset」関数の呼び出しにより、バッファー「pNewName」のアンダーフローが発生します。 sos strike.cpp 12016
• V512「memset」関数を呼び出すと、バッファー「pExpression」のアンダーフローが発生します。 sos strike.cpp 12024
• V512「memset」関数を呼び出すと、バッファー「pFilterName」のアンダーフローが発生します。 sos strike.cpp 12039

V598 「memcpy」関数は、「GenTree」クラスのフィールドをコピーするために使用されます。 これにより、仮想テーブルポインターが破損します。 ClrJit compiler.hpp 1344

 struct GenTree { .... #if DEBUGGABLE_GENTREE virtual void DummyVirt() {} #endif // DEBUGGABLE_GENTREE .... }; void GenTree::CopyFrom(const GenTree* src, Compiler* comp) { .... memcpy(this, src, src->GetNodeSize()); .... } 

プリプロセッサ変数「DEBUGGABLE_GENTREE」が宣言されている場合、仮想関数が定義されます。 次に、クラスには仮想メソッドのテーブルへのポインタが含まれ、そのようにコピーすることはできなくなります。

V598 「memcpy」関数は、「GCStatistics」クラスのフィールドをコピーするために使用されます。 これにより、仮想テーブルポインターが破損します。 cee_wks gc.cpp 287

 struct GCStatistics : public StatisticsBase { .... virtual void Initialize(); virtual void DisplayAndUpdate(); .... }; GCStatistics g_LastGCStatistics; void GCStatistics::DisplayAndUpdate() { .... memcpy(&g_LastGCStatistics, this, sizeof(g_LastGCStatistics)); .... } 

この場所では、デバッグモードだけでなく、誤ったコピーが実行されます。

V698式 'memcmp（....）== -1'は正しくありません。 この関数は、値 '-1'だけでなく、負の値も返すことができます。 代わりに 'memcmp（....）<0'の使用を検討してください。 sos util.cpp 142

 bool operator( )(const GUID& _Key1, const GUID& _Key2) const { return memcmp(&_Key1, &_Key2, sizeof(GUID)) == -1; } 

'memcmp'関数の結果を1または-1の値と比較することは正しくありません。 そのような構造の操作性は、ライブラリ、コンパイラ、その設定、オペレーティングシステム、その容量などに依存します。 この場合、「<0」、「0」または「> 0」の3つの状態のいずれかを確認する必要があります。

同様の場所：

• V698式 'wcscmp（....）== -1'は正しくありません。 この関数は、値 '-1'だけでなく、負の値も返すことができます。 代わりに「wcscmp（....）<0」を使用することを検討してください。 sos strike.cpp 3855

ポインターについて

V522ヌルポインター「hp」の逆参照が行われる場合があります。 cee_wks gc.cpp 4488

 heap_segment* gc_heap::get_segment_for_loh (size_t size #ifdef MULTIPLE_HEAPS , gc_heap* hp #endif //MULTIPLE_HEAPS ) { #ifndef MULTIPLE_HEAPS gc_heap* hp = 0; #endif //MULTIPLE_HEAPS heap_segment* res = hp->get_segment (size, TRUE); .... } 

「MULTIPLE_HEAPS」が定義されていない場合、トラブルが発生します。 ポインターはゼロになります。

V595 nullptrに対して検証される前に、「ツリー」ポインターが使用されました。 行を確認してください：6970、6976。ClrJit gentree.cpp 6970

 void Compiler::gtDispNode(GenTreePtr tree, ....) { .... if (tree->gtOper >= GT_COUNT) { printf(" **** ILLEGAL NODE ****"); return; } if (tree && printFlags) { /* First print the flags associated with the node */ switch (tree->gtOper) { .... } .... } .... } 

ポインターの有効性がチェックされるとき、ただし参照解除後にソースコードに場所があります。

リスト全体： CoreCLR_V595.txt

追加のチェック

余分なコードが有害ではない場合でも、その存在は開発の注意をより重要な場所から単にそらすことができます。

V503これは無意味な比較です：pointer> =0。cee_wks gc.cpp 21707

 void gc_heap::make_free_list_in_brick (BYTE* tree, make_free_args* args) { assert ((tree >= 0)); .... } 

これがポインターチェックです。 その他の例：

• V503これは無意味な比較です：pointer> =0。cee_wks gc.cpp 23204
• V503これは無意味な比較です：pointer> =0。cee_wks gc.cpp 27683

V547式 'maxCpuId> = 0'は常にtrueです。 符号なしの型の値は常に> = 0です。cee_wks codeman.cpp 1219

 void EEJitManager::SetCpuInfo() { .... unsigned char buffer[16]; DWORD maxCpuId = getcpuid(0, buffer); if (maxCpuId >= 0) { .... } 

DWORDタイプのみを使用した同様の例。

V590 'wzPath [0]！= L' \ 0 '&& wzPath [0] == L' \\ ''式の検査を検討してください。 表現が過剰であるか、誤植が含まれています。 cee_wks path.h 62

 static inline bool HasUncPrefix(LPCWSTR wzPath) { _ASSERTE(!clr::str::IsNullOrEmpty(wzPath)); return wzPath[0] != W('\0') && wzPath[0] == W('\\') && wzPath[1] != W('\0') && wzPath[1] == W('\\') && wzPath[2] != W('\0') && wzPath[2] != W('?'); } 

この機能は、次のオプションに簡略化できます。

 static inline bool HasUncPrefix(LPCWSTR wzPath) { _ASSERTE(!clr::str::IsNullOrEmpty(wzPath)); return wzPath[0] == W('\\') && wzPath[1] == W('\\') && wzPath[2] != W('\0') && wzPath[2] != W('?'); } 

このような別の場所：

• V590この表現を調べることを検討してください。 表現が過剰であるか、誤植が含まれています。 cee_wks path.h 72

V571定期的なチェック。 「if（moduleInfo [MSCORWKS] .baseAddr == 0）」条件は、749行目で既に検証されています。sos util.cpp 751

 struct ModuleInfo { ULONG64 baseAddr; ULONG64 size; BOOL hasPdb; }; HRESULT CheckEEDll() { .... // Do we have clr.dll if (moduleInfo[MSCORWKS].baseAddr == 0) //<== { if (moduleInfo[MSCORWKS].baseAddr == 0) //<== g_ExtSymbols->GetModuleByModuleName ( MAIN_CLR_MODULE_NAME_A,0,NULL, &moduleInfo[MSCORWKS].baseAddr); if (moduleInfo[MSCORWKS].baseAddr != 0 && //<== moduleInfo[MSCORWKS].hasPdb == FALSE) { .... } .... } .... } 

2番目の場合、「baseAddr」はチェックできなくなります。

V704 'this == nullptr'式は避ける必要があります-'this 'ポインターがNULLになることはないため、この式は新しいコンパイラーでは常にfalseです。 ClrJit gentree.cpp 12731

 bool FieldSeqNode::IsFirstElemFieldSeq() { if (this == nullptr) return false; return m_fieldHnd == FieldSeqStore::FirstElemPseudoField; } 

C ++標準によると、thisポインターは決してnullにできません。 このようなコードの考えられる結果は、 V704診断の説明に詳細に記載されています。 そのようなコードがVisual C ++コンパイラによるコンパイル後に正しく機能するという事実は幸運であり、正直に頼ることはできません。

全リスト： CoreCLR_V704.txt

V668 「new」演算子を使用してメモリが割り当てられたため、「newChunk」ポインターをnullに対してテストしても意味がありません。 メモリ割り当てエラーの場合、例外が生成されます。 ClrJit stresslog.h 552

 FORCEINLINE BOOL GrowChunkList () { .... StressLogChunk * newChunk = new StressLogChunk (....); if (newChunk == NULL) { return FALSE; } .... } 

「new」演算子がメモリを割り当てられなかった場合、C ++言語標準に従って、例外std :: bad_alloc（）がスローされます。 したがって、ゼロに等しいことを示すポインターをチェックすることは意味がありません。

そのような場所を確認することをお勧めします。完全なリスト： CoreCLR_V668.txtです。

おわりに

最近立ち上げられたCoreCLRプロジェクトは、クローズドソースソフトウェアがどのように見えるかの良い例です。 このトピックについては常に議論が続けられており、ここに反省と議論の別の理由があります。

私たちにとって、大規模なプロジェクトでは何らかのエラーを見つけることができ、静的アナライザーへの最適なアプリケーションは定期的なチェックであることが重要です。 怠けずにPVS-Studioをダウンロードして 、プロジェクトを確認してください。

この記事は英語です。

英語を話す聴衆とこの記事を共有したい場合は、翻訳へのリンクを使用してください：Svyatoslav Razmyslov。 PVS-Studio：CoreCLRの25の疑わしいコードフラグメント 。