PVS- स्टूडियो कोड विश्लेषक के साथ TortoiseSVN को रीचेक करना

हमने TortoiseSVN डेवलपर्स को थोड़ी देर के लिए PVS-Studio विश्लेषक के लिए एक मुफ्त कुंजी भेजी। जब तक उनके पास इसका उपयोग करने का समय नहीं था, मैंने तुरंत कछुआ स्रोत कोड डाउनलोड करने और खुद विश्लेषण करने का फैसला किया। लक्ष्य स्पष्ट है। पीवीएस-स्टूडियो के विज्ञापन के लिए एक और छोटा लेख।

हमने पहले ही TortoiseSVN प्रोजेक्ट का परीक्षण कर लिया है। बहुत समय पहले की बात है। परियोजना का सत्यापन पीवीएस-स्टूडियो 4.00 की रिलीज के साथ हुआ, जहां सामान्य नैदानिक ​​नियम पहली बार सामने आए।

समय-समय पर, हम नियमित रूप से उपकरण का उपयोग करने के लाभों को प्रदर्शित करने के लिए चेक दोहराते हैं। यह एक या दो बार परियोजना की जांच करने के लिए कोई मतलब नहीं है। एक परिवर्तनशील कोड में नई त्रुटियां लगातार दिखाई देती हैं। और फिर धीरे-धीरे और दुख से सही किया गया। तदनुसार, पीवीएस-स्टूडियो के दैनिक उपयोग के साथ अधिकतम लाभ प्राप्त किया जाएगा। बेहतर अभी तक, वृद्धिशील विश्लेषण का उपयोग कर।

तो, आइए देखें कि पीवीएस-स्टूडियो संस्करण 5.05 का उपयोग करके परियोजना में क्या दिलचस्प पाया गया। TortoiseSVN के लिए स्रोत कोड 06/19/2013 को http://tortoisesvn.googlecode.com/svn/trunk से लिए गए थे। वैसे, TortoiseSVN परियोजना बहुत उच्च गुणवत्ता वाली है और इसमें उपयोगकर्ता-प्रोग्रामरों का एक विशाल डेटाबेस है। इसलिए यदि आप कम से कम कुछ पाते हैं, तो यह पहले से ही एक बड़ी उपलब्धि है।

अजीब स्थिति है

static void ColouriseA68kDoc (....) { if (((sc.state == SCE_A68K_NUMBER_DEC) && isdigit(sc.ch)) .... || ((sc.state == SCE_A68K_MACRO_ARG) && isdigit(sc.ch)) || ((sc.state == SCE_A68K_MACRO_ARG) && isdigit(sc.ch)) .... } 

नैदानिक ​​संदेश: V501 समान उप-अभिव्यक्तियाँ हैं ('(sc.state == 11) && isdigit (sc.ch)' बाईं ओर और 'दाईं ओर' ऑपरेटर। lexa68k.cxx 160

दो समान तुलनाएँ हैं। कोई टाइपो हो सकता है।

एक टाइपो संभवतः निम्नलिखित कोड में मौजूद है। चर 'आरवी' का मान दो बार जांचा जाता है।

 struct hentry * AffixMgr::compound_check( .... if (rv && forceucase && (rv) && ....) .... } 

डायग्नोस्टिक संदेश: V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: rv && forceucase && (rv):

• affixmgr.cxx 1784
• affixmgr.cxx 1879

निम्नलिखित कोड स्निपेट:

 bool IsAllASCII7 (const CString& s) { for (int i = 0, count = s.GetLength(); i < count; ++i) if (s[i] >= 0x80) return false; return true; } 

नैदानिक ​​संदेश: V547 अभिव्यक्ति का [i]> = 0x80 'हमेशा गलत होता है। चार प्रकार के मूल्य सीमा: [-128, 127]। logdlgfilter.cpp 34

IsAllASCII7 () फ़ंक्शन हमेशा 'सही' देता है। स्थिति 's [i]> = 0x80' हमेशा झूठी होती है। प्रकार 'चार' के एक चर का मान 0x80 से अधिक या उसके बराबर नहीं हो सकता है।

एक गलत तुलना के साथ निम्नलिखित कोड स्निपेट:

 int main(int argc, char **argv) { .... DWORD ticks; .... if (run_timers(now, &next)) { ticks = next - GETTICKCOUNT(); if (ticks < 0) ticks = 0; } else { ticks = INFINITE; } .... } 

नैदानिक ​​संदेश: V547 अभिव्यक्ति 'टिक्स <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Winplink.c 635

चर 'टिक' अहस्ताक्षरित है। इसका मतलब है कि "अगर (टिक <0)" की जाँच करने का कोई मतलब नहीं है। ओवरफ्लो की स्थिति पर कार्रवाई नहीं की जाएगी।

उस त्रुटि पर विचार करें जिसके कारण strncmp फ़ंक्शन स्ट्रिंग्स की पूरी तरह से तुलना नहीं करता है।

 int AffixMgr::parse_convtable(...., const char * keyword) { char * piece; .... if (strncmp(piece, keyword, sizeof(keyword)) != 0) { .... } 

डायग्नोस्टिक संदेश: V579 strncmp फ़ंक्शन सूचक और उसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। तीसरे तर्क का निरीक्षण करें। affixmgr.cxx 3654

'साइज़ोफ़' ऑपरेटर सूचक के आकार की गणना करता है। इस मान का स्ट्रिंग लंबाई से कोई लेना-देना नहीं है।

संदिग्ध स्ट्रिंग गठन

एक चर संख्या वाले तर्क हमेशा हर जगह होते हैं, और हमेशा खतरनाक होते हैं।

 class CTSVNPath { .... private: mutable CString m_sBackslashPath; mutable CString m_sLongBackslashPath; mutable CString m_sFwdslashPath; .... }; const FileStatusCacheEntry * SVNFolderStatus::BuildCache( const CTSVNPath& filepath, ....) { .... CTraceToOutputDebugString::Instance() (_T(__FUNCTION__) _T(": building cache for %s\n"), filepath); .... } 

डायग्नोस्टिक संदेश: V510 'ऑपरेटर ()' फ़ंक्शन को दूसरे वास्तविक तर्क के रूप में वर्ग-प्रकार चर प्राप्त करने की उम्मीद नहीं है:

• svnfolderstatus.cpp 150
• svnfolderstatus.cpp 355
• svnfolderstatus.cpp 360

निर्दिष्ट "% s" इंगित करता है कि फ़ंक्शन वास्तविक तर्क के रूप में एक स्ट्रिंग की अपेक्षा करता है। हालाँकि, चर 'filepath' एक स्ट्रिंग नहीं है, लेकिन एक जटिल ऑब्जेक्ट जिसमें कई लाइनें हैं। मुझे यह कहने में हानि हो रही है कि क्या प्रिंट आउट होगा और क्या यह कोड बिल्कुल गिर जाएगा।

इस तरह के 'प्रिंटफ ()' जैसे कार्यों का उपयोग करना खतरनाक है: "प्रिंटफ (myStr);"। यदि नियंत्रण क्वालिफ़ायर 'myStr' के अंदर मौजूद हैं, तो प्रोग्राम कुछ ऐसा प्रिंट कर सकता है जो दुर्घटनाग्रस्त नहीं होना चाहिए या हो सकता है।

TortoiseSVN से कोड पर विचार करें:

 BOOL CPOFile::ParseFile(....) { .... printf(File.getloc().name().c_str()); .... } 

डायग्नोस्टिक मैसेज: V618 'प्रिंटफ' फ़ंक्शन को इस तरह से कॉल करना खतरनाक है, क्योंकि जो लाइन पास की जा रही है, उसमें प्रारूप विनिर्देश हो सकते हैं। सुरक्षित कोड का उदाहरण: प्रिंटफ ("% s", str); pofile.cpp 158

यदि फ़ाइल का नाम "myfile% s% i% s.txt" है, तो परिणाम विनाशकारी होगा।

नोट। हमारे पास प्रिंटफ () फ़ंक्शन का उपयोग करने के खतरों पर एक दिलचस्प नोट है ।

सरणियों का गलत शून्यकरण

मुझे नहीं पता कि TortoiseSVN के लिए यह कितना खतरनाक है कि वे बिना रीसेट किए बफ़र्स की सामग्री को छोड़ दें। शायद आम तौर पर सुरक्षित। हालाँकि, बफ़र्स को रीसेट करने के लिए कोड है। और चूंकि यह काम नहीं करता है, इसलिए इसके बारे में ध्यान देने योग्य है। त्रुटियां इस तरह दिखती हैं:

 static void sha_mpint(SHA_State * s, Bignum b) { unsigned char lenbuf[4]; .... memset(lenbuf, 0, sizeof(lenbuf)); } 

डायग्नोस्टिक मैसेज: V597 कंपाइलर 'मेमसेट' फंक्शन कॉल को डिलीट कर सकता है, जिसका इस्तेमाल 'लेनब्यूफ' बफर को फ्लश करने के लिए किया जाता है। RtlSecureZeroMemory () फ़ंक्शन का उपयोग निजी डेटा को मिटाने के लिए किया जाना चाहिए। sshdss.c 23

फ़ंक्शन से बाहर निकलने से पहले, सरणी 'lenbuf' को साफ़ किया जाना चाहिए। तब से सरणी का उपयोग नहीं किया जाता है, ऑप्टिमाइज़र 'मेमसेट' फ़ंक्शन को कॉल हटा देगा। ऐसा होने से रोकने के लिए, आपको विशेष कार्यों का उपयोग करने की आवश्यकता है।

अन्य स्थानों पर जहां संकलक 'मेमसेट ()' के लिए कॉल को हटा देगा:

• sshdss.c 37
• sshdss.c 587
• sshdes.c 861
• sshdes.c 874
• sshdes.c 890
• sshdes.c 906
• sshmd5.c 252
• sshrsa.c 113
• sshpubk.c 153
• sshpubk.c 361
• sshpubk.c 1121
• sshsha.c 256

अजीब

 BOOL InitInstance(HINSTANCE hResource, int nCmdShow) { .... app.hwndTT; // handle to the ToolTip control .... } 

नैदानिक ​​संदेश: V607 मालिकाना अभिव्यक्ति 'app.hwTTT'। tortoiseblame.cpp 1782

सबसे अधिक संभावना है, 'InitInstance ()' फ़ंक्शन में, सदस्य 'hwndTT' को किसी चीज़ के साथ आरंभ किया जाना चाहिए। हालांकि, एक टाइपो के कारण, कोड अधूरा निकला।

64-बिट त्रुटियाँ

मैं त्रुटियों के लिए बहुत सतही खोज करता हूं। मैं चौकस हूं, बस इतना है कि मेरे पास लेख लिखने के लिए पर्याप्त उदाहरण हैं। नहीं, मैं बायक नहीं हूं। यह सिर्फ इतना है कि परियोजना के लेखक अभी भी मुझसे बेहतर विश्लेषण करेंगे।

मैं 64-बिट त्रुटियों को और भी अधिक सतही रूप से देखता हूं। परियोजना की संरचना को जाने बिना यह निर्धारित करना बहुत मुश्किल है, यह या वह त्रुटि हो सकती है या नहीं।

मैं केवल कुछ खतरनाक स्थानों को दूंगा:

 void LoginDialog::CreateModule(void) { .... DialogBoxParam(g_hmodThisDll, MAKEINTRESOURCE(IDD_LOGIN), g_hwndMain, (DLGPROC)(LoginDialogProc), (long)this); .... } 

डायग्नोस्टिक संदेश: V220 प्रकार की कास्टिंग का संदिग्ध क्रम: मेमसाइज़ -> 32-बिट पूर्णांक -> मेम्सेज़। डाले जा रहे मूल्य: 'यह'। logindialog.cpp 105

इसके लिए सूचक स्पष्ट रूप से लंबा टाइप करने के लिए डाला गया है। फिर इसे LPARAM (LONG_PTR) टाइप करने के लिए इसका विस्तार किया गया है। महत्वपूर्ण बात यह है कि सूचक थोड़ी देर के लिए 'लंबे' में बदल जाता है। यदि प्रोग्राम 64-बिट है तो यह खराब है। एक सूचक 64 बिट्स पर कब्जा कर लेता है। Win64 में 'लंबा' प्रकार अभी भी एक 32-बिट प्रकार है। नतीजतन, 64-बिट चर के सबसे महत्वपूर्ण बिट खो जाएंगे।

यदि ऑब्जेक्ट को 4 जीबी रैम से कम में बनाया जाता है, तो प्रोग्राम अप्रत्याशित हो जाएगा। इस तरह की घटना की संभावना निश्चित रूप से महान नहीं है, लेकिन इस तरह की त्रुटि को पुन: पेश करना बेहद मुश्किल है।

सही कोड: DialogBoxParam (...., (LPARAM) यह);

एक और खतरनाक कास्ट पर विचार करें:

 static int cmpforsearch(void *av, void *bv) { Actual_Socket b = (Actual_Socket) bv; unsigned long as = (unsigned long) av, bs = (unsigned long) b->s; if (as < bs) return -1; if (as > bs) return +1; return 0; } 

नैदानिक ​​संदेश: V205 सूचक प्रकार का 32-बिट पूर्णांक प्रकार में रूपांतरण: (अहस्ताक्षरित लंबा) av:

• winnet.c 139
• winhandl.c 359
• winhandl.c 348

पॉइंटर्स स्पष्ट रूप से 'अहस्ताक्षरित लंबे' टाइप करने के लिए डाले जाते हैं और चर में 'ए' और 'बी एस' के रूप में रखे जाते हैं। चूंकि इस मामले में पते के उच्च बिट खो सकते हैं, तुलना सही ढंग से काम नहीं कर सकती है। यह आम तौर पर स्पष्ट नहीं है कि पॉइंटर्स को यहां पूर्णांक प्रकारों में क्यों डाला जाता है। आप बस संकेत की तुलना कर सकते हैं।

पदावनत नल सूचक चेक

'नया' ऑपरेटर, जब यह मेमोरी आवंटित नहीं कर सकता है, बहुत पहले NULL नहीं लौटा था। यह एक अपवाद std :: bad_alloc फेंकता है। बेशक, आप ऑपरेटर को 'नया' रिटर्न 0 बना सकते हैं, लेकिन यह अब अप्रासंगिक है।

फिर भी, निम्नलिखित कोड कार्यक्रमों में रहते हैं:

 int _tmain(....) { .... pBuf = new char[maxlength]; if (pBuf == NULL) { _tprintf(_T("Could not allocate enough memory!\n")); delete [] wc; delete [] dst; delete [] src; return ERR_ALLOC; } .... } 

डायग्नोस्टिक संदेश: V668 नल के खिलाफ 'pBuf' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा।

• subwcrev.cpp 912
• repositorybrowser.cpp 2565
• repositorybrowser.cpp 4225
• svnstatuslistctct.cpp 5254
• svnprogressdlg.cpp 2357
• Bugtraqassociations.cpp 116
• xmessagebox.cpp 792
• xmessagebox.cpp 797
• hyperlink_base.cpp 166
• affixmgr.cxx 272
• hashmgr.cxx 363
• hashmgr.cxx 611

और इसलिए यह चला जाता है

कई त्रुटियों के बारे में जो मुझे कोड का अध्ययन करते समय सामना करते हैं, मैं लेखों में नहीं लिखता हूं। तथ्य यह है कि वे कार्यक्रम में हस्तक्षेप नहीं करते हैं। इस बार मैंने ऐसे कुछ मामलों के बारे में लिखने का फैसला किया। यह देखने के लिए बहुत ही मजेदार स्थिति है जब कोई प्रोग्राम ठीक से काम नहीं करता है, क्योंकि यह भाग्य के कारण होता है।

 void CBaseView::OnContextMenu(CPoint point, DiffStates state) { .... popup.AppendMenu(MF_STRING | oWhites.HasTrailWhiteChars ? MF_ENABLED : (MF_DISABLED|MF_GRAYED), POPUPCOMMAND_REMOVETRAILWHITES, temp); .... } 

डायग्नोस्टिक संदेश: V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' की तुलना में ऑपरेटर की प्राथमिकता कम है। ऑपरेटर। baseview.cpp 2246

चर के मान के आधार पर 'oWhites.HasTrailWhiteChars', स्थिरांक के संयोजनों में से एक की आवश्यकता है:

• MF_STRING | MF_ENABLED
• MF_STRING | MF_DISABLED | MF_GRAYED

लेकिन कोड उस तरह से काम नहीं करता है। ऑपरेशन प्राथमिकता '|' ऑपरेशन की प्राथमिकता से अधिक? ''। हम स्पष्टता के लिए कोष्ठक डालते हैं:

(MF_STRING | oWhites.HasTrailWhiteChars) MF_ENABLED: MF_DISABLED | MF_GRAYED

कोड केवल इस तथ्य के कारण सही ढंग से काम करता है कि निरंतर 'MF_STRING' 0. है। परिणाम पर इसका कोई प्रभाव नहीं है। नतीजतन, गलत अभिव्यक्ति सही तरीके से काम करती है।

भाग्य के एक और उदाहरण पर विचार करें। TortoiseSVN में, HWND प्रकार को अक्सर 'अहस्ताक्षरित' प्रकार के रूप में उपयोग किया जाता है। इसके लिए, स्पष्ट प्रकार के रूपांतरण किए जाने चाहिए। उदाहरण के लिए, जैसा कि निम्नलिखित कार्यों में दिखाया गया है:

 HWND m_hWnd; UINT_PTR uId; INT_PTR CBaseView::OnToolHitTest(....) const { .... pTI->uId = (UINT)m_hWnd; .... } UINT_PTR idFrom; HWND m_hWnd; BOOL CBaseView::OnToolTipNotify( UINT, NMHDR *pNMHDR, LRESULT *pResult) { if (pNMHDR->idFrom != (UINT)m_hWnd) return FALSE; .... } 

या, उदाहरण के लिए, टाइप HWND के एक वैरिएबल का मान मुद्रित किया जाता है जैसे कि यह 'लंबे' प्रकार का था।

 bool CCommonAppUtils::RunTortoiseProc(....) { .... CString sCmdLine; sCmdLine.Format(L"%s /hwnd:%ld", (LPCTSTR)sCommandLine, AfxGetMainWnd()->GetSafeHwnd()); .... } 

औपचारिक रूप से, यह कोड गलत है। तथ्य यह है कि टाइप 'HWND' एक पॉइंटर है। इसका मतलब है कि इसे 32-बिट पूर्णांक प्रकारों में नहीं बदला जा सकता है। और पीवीएस-स्टूडियो विश्लेषक इस बारे में चिंतित हैं, चेतावनी दे रहे हैं।

लेकिन दिलचस्प बात यह है कि यह कोड पूरी तरह से सही ढंग से काम करेगा!

HWND प्रकार का उपयोग विभिन्न सिस्टम ऑब्जेक्ट्स के साथ काम करने के लिए विंडोज में उपयोग किए जाने वाले डिस्क्रिप्टर को स्टोर करने के लिए किया जाता है। इसी प्रकार के हैंण्डल, HMENU, HPALETTE, HBITMAP इत्यादि।

हालाँकि वर्णनकर्ता 64-बिट पॉइंटर्स हैं, अधिक अनुकूलता के लिए (उदाहरण के लिए, 32-बिट और 64-बिट प्रक्रियाओं के बीच अंतर के लिए) वे केवल 32-बिट का उपयोग करते हैं। अधिक जानकारी के लिए " Microsoft इंटरफ़ेस डेफिनिशन लैंग्वेज (MIDL): 64-बिट पोर्टिंग गाइड " (USER और GDI हैंडल हस्ताक्षरित 32b मान हैं) देखें।

HWND प्रकार को 32-बिट प्रकारों में रखने पर, डेवलपर्स शायद ही इन मान्यताओं पर आधारित थे। सबसे अधिक संभावना है, यह एक बहुत साफ कोड नहीं है जो विंडोज एपीआई डेवलपर्स के भाग्य और प्रयासों के कारण सही ढंग से काम करता है।

निष्कर्ष

विकास के दौरान नियमित रूप से स्थैतिक विश्लेषण का उपयोग करें, और आप शुरुआती चरणों में कई त्रुटियां पाएंगे। मैं स्वाभाविक रूप से सलाह देता हूं कि आप सबसे पहले पीवीएस-स्टूडियो कोड विश्लेषक से परिचित हों। हालांकि, कई अन्य अच्छे कोड विश्लेषक हैं: स्थिर कोड विश्लेषण उपकरण ।

संदर्भ

अतिरिक्त लिंक जो लेख में वर्णित कुछ सूक्ष्म बिंदुओं को स्पष्ट कर सकते हैं।

1. ज्ञान का आधार। ओवरराइटिंग मेमोरी - क्यों?
2. प्रलेखन। V668। अशक्त के खिलाफ सूचक का परीक्षण करने में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था।
3. ज्ञान का आधार। 64-बिट प्रोग्राम में इंट्री करने के लिए पॉइंटर को सही तरीके से कैसे डालें?
4. कार्पोव एंड्री, एव्जेनी रयज़कोव। 64-बिट C / C ++ अनुप्रयोगों के विकास के लिए सबक ।