नृशंस, दुनिया! हमने पीवीएस-स्टूडियो 4.00 को मुक्त सामान्य-उद्देश्य विश्लेषक के साथ जारी किया

हम प्रोग्रामर के ध्यान में C / C ++ अनुप्रयोगों के स्रोत कोड में त्रुटियों को खोजने के लिए एक नया उपकरण लाते हैं। पीवीएस-स्टूडियो विश्लेषक के हिस्से के रूप में, सामान्य नियमों का एक नया सेट लागू किया गया है। यह कार्यक्षमता वर्तमान में निःशुल्क है। आप पीवीवी-स्टूडियो को http://www.viva64.com/en/pvs-studio-download/ पर डाउनलोड कर सकते हैं।



लेख संक्षेप में पीवीएस-स्टूडियो की नई विशेषताओं का वर्णन करता है। TortoiseSVN परियोजना के स्रोत कोड के स्थिर विश्लेषण का उपयोग करके, हम नई नैदानिक ​​क्षमताओं के उपयोग का प्रदर्शन करेंगे।



PVS-Studio एक आधुनिक स्रोत कोड विश्लेषक है जो Microsoft Visual Studio 2005/2008/2010 के साथ एकीकृत होता है। विश्लेषक आपको चेतावनी सूची के साथ आसानी से काम करने और अपने काम के लिए कई प्रोसेसर कोर का उपयोग करने की अनुमति देता है। PVS-Studio का उद्देश्य C / C ++ / C ++ 0x में आधुनिक विंडोज एप्लिकेशन के डेवलपर्स से है।



अब तक, पीवीएस-स्टूडियो में नियमों के दो सेट शामिल थे। सबसे पहले 64-बिट कार्यक्रमों में दोषों का पता लगाना है। दूसरा ओपनएमपी तकनीक के आधार पर निर्मित समानांतर कार्यक्रमों में दोषों का पता लगाने के लिए है।



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



अब आप पीवीएस-स्टूडियो 4.00 बीटा डाउनलोड करके नियमों के नए सेट से खुद को परिचित कर सकते हैं। सुधार के लिए बग और सुझावों के संबंध में आपसे टिप्पणी प्राप्त करने में हमें खुशी होगी। मैं तुरंत ध्यान देना चाहता हूं कि एक शुरुआत के लिए हमने केवल 50 सामान्य-उद्देश्य नियमों को लागू किया। यह एक सा है। इसलिए, यदि आप तुरंत पीवीएस-स्टूडियो डाउनलोड करते हैं और कोशिश करते हैं, तो आपको अपने कोड में कुछ दिलचस्प नहीं मिलेगा, निष्कर्ष पर नहीं जाएं। हमारा सुझाव है कि आप भविष्य में फिर से पीवीएस-स्टूडियो की कोशिश करें, जब चेक का सेट काफी बढ़ जाएगा। हम निकट भविष्य में नैदानिक ​​नियमों के आधार के विस्तार पर सक्रिय रूप से काम करने की योजना बनाते हैं (यदि आपके पास पर्याप्त स्वास्थ्य है और भाग्यशाली हैं)।



आइए TortoiseSVN उदाहरण का उपयोग करके नए PVS-Studio नियम के उपयोग को प्रदर्शित करते हैं। TortoiseSVN विंडोज शेल के विस्तार के रूप में लागू किए गए सबवर्सन संस्करण नियंत्रण प्रणाली के लिए एक क्लाइंट है। TortoiseSVN कई डेवलपर्स के लिए अच्छी तरह से जाना जाता है, और मुझे लगता है कि इस एप्लिकेशन को और अधिक विस्तार से वर्णन करने का कोई मतलब नहीं है। मैं केवल यह नोट करता हूं कि 2007 में SourceForge.net TortoiseSVN को "डेवलपर्स के लिए उपकरण और उपयोगिताओं" श्रेणी में सर्वश्रेष्ठ परियोजना के रूप में मान्यता दी गई थी।

चरण 1

कंपनी की वेबसाइट "सॉफ्टवेयर सत्यापन के सिस्टम" एलएलसी से पीवीएस-स्टूडियो डाउनलोड करें (यह हम है)। मुझे आशा है कि आप प्रसन्न होंगे कि आपको किसी प्रश्नावली को भरने या कैप्चा हल करने की आवश्यकता नहीं है। बस डाउनलोड करें ।

चरण 2

पीवीएस-स्टूडियो स्थापित करें। आप सुरक्षित रूप से "अगला" बटन पर क्लिक कर सकते हैं। आपको कुछ भी कॉन्फ़िगर करने की आवश्यकता नहीं है। पीवीएस-स्टूडियो वितरण डिजिटल रूप से हस्ताक्षरित है। हालांकि, कुछ एंटीवायरस अभी भी विजुअल स्टूडियो में एकीकरण से संबंधित कार्यों से सावधान रह सकते हैं। सभी को अनुमति है।

चरण 3

TortoiseSVN प्रोजेक्ट स्रोत पैकेज डाउनलोड करें। हमने स्रोत कोड संस्करण 1.6.11 के साथ काम किया।

चरण 4

TortoiseSVN प्रोजेक्ट खोलें और विश्लेषण शुरू करें। ऐसा करने के लिए, मेरे पीवीएस-स्टूडियो में हम चेक सॉल्यूशन कमांड का चयन करेंगे।

चरण 5

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



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



खिड़की तीन बटन का एक सेट दिखाती है, जो तीन नियमों के संदेशों को प्रदर्शित करने के लिए जिम्मेदार है।





1) 64 - डायग्नोस्टिक संदेशों के बारे में 64-बिट दोष (Viva64);

2) एमपी - समानांतर दोष (विवाएमपी) के बारे में नैदानिक ​​संदेश;

3) जीए - सामान्य प्रकार के नैदानिक ​​संदेश।



हम केवल सामान्य नियम सेट (GA) में रुचि रखते हैं। अन्य बटन दबाएं, और सूची में अतिरिक्त संदेश तुरंत छिपाए जाएंगे।





हम विश्लेषण पूरा होने का इंतजार कर रहे हैं।

चरण 6

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



सभी चेतावनियों को महत्व के 3 स्तरों में विभाजित किया गया है (यह पीवीएस-स्टूडियो 4.00 में नया है)। आमतौर पर, यह केवल पहले और दूसरे स्तर को देखने के लिए समझ में आता है। पीवीएस-स्टूडियो 4.00 बीटा ने 33 प्रथम-स्तरीय अलर्ट, 14 द्वितीय-स्तरीय अलर्ट और 8 तृतीय-स्तरीय अलर्ट जारी किए।



यह प्रथम स्तर के अलर्ट के साथ शुरूआत करने के लायक है। इसलिए, आप उस बटन को अक्षम कर सकते हैं जो दूसरे स्तर के संदेशों के आउटपुट को इंगित करता है। तीसरा स्तर पहले से ही डिफ़ॉल्ट रूप से अक्षम है।

चरण 7

विश्लेषक द्वारा पता लगाए गए कोड में दिलचस्प स्थानों पर विचार करें।

स्थिति 1

बहुत शुरुआत में, दो संदेश एक ही फ़ंक्शन के होते हैं। यह आशा की जाती है कि यह सुविधा कहीं भी विशेष रूप से उपयोग नहीं की जाती है।



V530 'खाली' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। referencemenu.cpp 434



V530 फ़ंक्शन 'निष्कासन' के वापसी मूल्य का उपयोग करने की आवश्यकता है। referencemenu.cpp 442

  STDMETHODIMP CShellExt :: प्रारंभिक (....)
 {
   ...
   ignoredprops.empty ();
   for (int p = 0; p <props.GetCount (); ++ p)
   {
     अगर (सहारा। GetItemName (p)
           तुलना (SVN_PROP_IGNORE) == 0)
     {
       std :: string st = props.GetItemValue (p);
       ignoredprops = UTF8ToWide (st.c_str ());
       // सभी एस्केप चार्ट को हटा दें ('\\')
       std :: remove (अनदेखा करना)
                   ignoredprops.end (), '\\');
       तोड़;
     }
   }
   ...
 } 

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



चेतावनी V530 हमें बताती है कि "ignoredprops.empty ()" लाइन को बिल्कुल भी स्पष्ट नहीं करता है, और "std :: remove ()" वास्तव में वर्णों को नहीं हटाता है।

स्थिति 2

यह जाँचता है कि प्रकार 'चर' का चर मान 0x80 से अधिक या बराबर है।



V547 अभिव्यक्ति 'c> = 0x80' हमेशा झूठी होती है। हस्ताक्षरित चार प्रकार की मूल्य सीमा: [-128, 127]। pathutils.cpp 559

  CSathring CPathUtils :: PathUnescape (const char * path)
 {
   // त्वरित पथ का प्रयास करें
   size_t i = 0;
   के लिए; चार सी = पथ [i]; ++ i)
     अगर ((c> = 0x80) || (c == '%'))
     {
       // त्वरित पथ के लिए काम नहीं करता है
       // गैर-लैटिन या बच गए वर्ण
       std :: string utf8Path (पाथ);
       CPathUtils :: Unescape (& utf8Path [0]);
       सीवनकोडाइल्ट्स वापस करें :: UTF8ToUTF16 (utf8Path);
     }
   ...
 } 

संदेश V547 सूचित करता है कि ऐसा चेक व्यर्थ है। 'Char' प्रकार का मान हमेशा 0x80 से कम होगा, जिसका अर्थ है कि स्थिति हमेशा झूठी है। और शायद इस त्रुटि के कारण, टिप्पणी "त्वरित पथ गैर-लैटिन या बच गए वर्ण के लिए काम नहीं करता है" कोड में लिखा गया था। बेशक यह काम नहीं करता है, लेकिन इसलिए नहीं कि स्ट्रिंग को परिवर्तित नहीं किया जा सकता है। जब एक गैर-लैटिन चरित्र सामने आता है, तो हम बस 'अगर' ऑपरेटर के शरीर में नहीं जाते हैं।

स्थिति 3

CreateThread / ExitThread फ़ंक्शंस का उपयोग करके कई थ्रेड्स बनाए और मारे जाते हैं। और, इसलिए, हम धागे के ढेर को जल्दी से समाप्त करने का जोखिम चलाते हैं या जब धागा समाप्त हो जाता है तो संसाधनों का हिस्सा खाली नहीं करता है। विवरण के लिए चेतावनी V513 का विवरण पढ़ें। यह _beginthreadex () और _endthreadex () फ़ंक्शन का उपयोग करने के लिए अधिक सुरक्षित है।



उदाहरण कोड देने का कोई मतलब नहीं है, लेकिन सभी संदेशों का पाठ समान है:



V513 CreateThread / ExitThread फ़ंक्शंस के बजाय _beginthreadex / _endthreadex फ़ंक्शंस का उपयोग करें। crashhandler.cpp 379

स्थिति ४

यह संबंधित TortoiseSVN उपयोगिताओं पर लागू होता है। यह बहुत संभावना है कि क्रैशलॉग के साथ काम करने पर यह दूसरे क्रैश के साथ समाप्त हो जाएगा।



V510 'Printf_s' फ़ंक्शन को चौथे वास्तविक तर्क के रूप में वर्ग-प्रकार के चर प्राप्त करने की उम्मीद नहीं है। excprpt.cpp 199

  स्ट्रिंग CExceptionReport :: getCrashLog ()
 {
   ...
   _tprintf_s (buf, _T ("% s \\% s.xml"),
   getenv ("टीईएमपी"), घुलनशीलता :: getAppName ());
   ...
 } 

संदेश V510 चेतावनी देता है कि टाइप करें std :: string का एक पैरामीटर पास करना बहुत खराब है। और फ़ंक्शन CUtility :: getAppName () बिल्कुल std :: string देता है। त्रुटि यह है कि आप ".c_str ()" लिखना भूल गए हैं। परिणाम या तो केवल गलत डेटा आउटपुट या प्रोग्राम क्रैश हो सकता है।

स्थिति ५

वे सरणी को खाली करना चाहते थे, लेकिन नहीं कर सके।



V530 'खाली' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। mailmsg.cpp 40

  CMailMsg और CMailMsg :: SetFrom (स्ट्रिंग sAddress,
                             स्ट्रिंग sName)
 {
    अगर (initIfNeeded ())
    {
       // केवल एक प्रेषक ने अनुमति दी
       अगर (m_from.size ())
          m_from.empty ();
       m_from.push_back (TStrStrPair (sAddress, sName));
    }
    वापसी * ​​यह;
 } 

फिर, V530 संदेश हमें बताता है कि "स्पष्ट ()", "खाली ()" के बजाय गलती से लिखा गया था।

स्थिति ६

और सेट्टो () फ़ंक्शन में, वे सरणी को भी साफ़ नहीं कर सके।



V530 'खाली' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। mailmsg.cpp 54

  CMailMsg और CMailMsg :: SetTo (string sAddress,
                           स्ट्रिंग sName)
 {
    अगर (initIfNeeded ())
    {
       // केवल एक प्राप्तकर्ता ने अनुमति दी
       अगर (m_to.size ())
          m_to.empty ();

       m_to.push_back (TStrStrPair (sAddress, sName));
    }
    वापसी * ​​यह;
 } 

स्थिति 7

बेशक, झूठी सकारात्मक हैं। यहाँ, उदाहरण के लिए, TortoiseSVN परियोजना में शामिल zlib लाइब्रेरी से एक कोड स्निपेट है। यहां कोई त्रुटि नहीं है, लेकिन V501 के साथ ऐसी जगह को चिह्नित करना बहुत उपयोगी है।



V501 बाईं और '-' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: आकार - आकार zutil.c 213

  voidpf zcalloc (अपारदर्शी, आइटम, आकार)
     voidpf अपारदर्शी;
     अहस्ताक्षरित आइटम;
     अहस्ताक्षरित आकार;
 {
   / * कंपाइलर को खुश करें * /
   अगर (अपारदर्शी) आइटम + = आकार - आकार;
   वापसी (voidpf) कॉलोक (आइटम, आकार);
 } 

संकलक निश्चित रूप से यहां खुश है, लेकिन घटाव संदिग्ध लग रहा है।

स्थिति 8

एन्कोडिंग के साथ अन्य अंधेरे स्थान हैं। यहाँ एक और शर्त है जो हमेशा झूठी होती है।



V547 अभिव्यक्ति '* utf8CheckBuf> = 0xF5' हमेशा गलत है। हस्ताक्षरित चार प्रकार की मूल्य सीमा: [-128, 127]। tortoiseblame.cpp 312

  BOOL TortoiseBlame :: OpenFile (const TCHAR * fileName)
 {
   ...
   // अवैध utf8 दृश्यों के लिए प्रत्येक पंक्ति की जाँच करें।
   // यदि एक पाया जाता है, तो हम इलाज करते हैं
   // ASCII के रूप में फ़ाइल, अन्यथा हम मान लेते हैं
   // UTF8 फ़ाइल।
   char * utf8CheckBuf = lineptr;
   जबकि (bUTF8) && (* utf8CheckBuf))
   {
     अगर (* utf8CheckBuf == 0xC0) ||
         (* utf8CheckBuf == 0xC1) ||
         (* utf8CheckBuf> = 0xF5))
     {
       bUTF8 = false;
       तोड़;
     }

    ...
   } 

वैसे, "" utf8CheckBuf == 0xC0 "," * utf8CheckBuf == 0xC1 "स्थितियां भी हमेशा झूठी होती हैं। इसलिए, कोड "bUTF8 = false;" कभी भी नियंत्रण प्राप्त नहीं करेगा। तथ्य यह है कि पीवीएस-स्टूडियो विश्लेषक ने अभिव्यक्ति को डांटा नहीं है "* utf8CheckBuf == 0xC0" एक दोष है। सुधार की सूची में दर्ज। अगले संस्करण में, हम इस पर शपथ लेंगे।

स्थिति ९

अगली पोस्ट इतनी सरल नहीं है। सैद्धांतिक रूप से, कोड में कोई त्रुटि है। व्यावहारिक रूप से - यह कोड काम करता है।



V507 पॉइंटर से लेकर लोकल एरे 'stringbuf' तक इस ऐरे के दायरे से बाहर रखा गया है। ऐसा पॉइंटर अमान्य हो जाएगा। mainwindow.cpp 277

  LRESULT CALLBACK CMainWindow :: WinMsgHandler (....)
 {
   ...
   अगर (pNMHDR-> कोड == TTN_GETDISPINFO)
   {
     LPTOOLTIPTEXT लैप्टेट;

     lpttt = (LPTOOLTIPTEXT) lParam;
     lpttt-> hinst = hResource;

     // संसाधन पहचानकर्ता निर्दिष्ट करें
     // दिए गए बटन के लिए वर्णनात्मक पाठ।
     TCHAR स्ट्रिंगबीफ [MAX_PATH] = {0};
     ...
     lpttt-> lpszText = stringbuf;
   }
   ...
 } 

नैदानिक ​​संदेश V507 चेतावनी देता है कि वस्तु का उपयोग उसके अस्तित्व के अंत के बाद किया जाता है। Statement if ’स्टेटमेंट के बॉडी से बाहर निकलने के बाद बफर iting stringbuf’ का इस्तेमाल किया जाएगा।



यदि 'stringbuf' एक क्लास ऑब्जेक्ट था, उदाहरण के लिए std :: string, तो यह कोड गलत व्यवहार करेगा। हम पहले से ही नष्ट की गई वस्तु का उपयोग करेंगे। लेकिन यहाँ, 'stringbuf' स्टैक पर बनाई गई एक सरणी है। Visual C ++ कंपाइलर स्टैक के इस खंड का पुन: उपयोग नहीं करता है, और बफर 'फ़ंक्शन' CMainWindow :: WinMsgHandler 'के अंत तक मौजूद रहेगा। इस प्रकार, कोई त्रुटि नहीं होगी, हालांकि कोड संभावित खतरनाक है।

स्थिति 10

और ऊपर उदाहरण के रूप में एक ही जगह है। फिर से, यह कोड है जो काम करता है, लेकिन नाजुक है।



V507 पॉइंटर से लेकर लोकल एरे 'stringbuf' तक इस ऐरे के दायरे से बाहर रखा गया है। ऐसा पॉइंटर अमान्य हो जाएगा। picwindow.cpp 443

  अगर ((HWND) wParam == m_AlphaSlider.GetWindow ()
 {
   LPTOOLTIPTEXT लैप्टेट;

   lpttt = (LPTOOLTIPTEXT) lParam;
   lpttt-> hinst = hResource;
   TCHAR स्ट्रिंगबीफ [MAX_PATH] = {0};
   _stprintf_s (stringbuf, .....);
   lpttt-> lpszText = stringbuf;
 } 

स्थिति ११

विध्वंसक में अपवादों को फेंकना और न फेंकना एक बुरा विचार है।



V509 विध्वंसक के अंदर 'थ्रो' ऑपरेटर को try..catch ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है। cachefileoutbuffer.cpp 52

  CCacheFileOutBuffer :: ~ CCacheFileOutBuffer ()
 {
   अगर (IsOpen)
   {
     streamOffsets.push_back (GetFileSize ());
     size_t lastOffset = streamOffsets [0];
     for (size_t i = 1,
          count = streamOffsets.size ();
          मैं <गिनती;  ++ i)
     {
       size_t ऑफसेट = स्ट्रीमऑफ़सेट [i];
       size_t size = ऑफसेट - lastOffset;

       अगर (आकार> = (DWORD) - (1))
         CStreamException ("बहुत बड़ी धारा") फेंकें;

       जोड़ें (DWORD) आकार);
       lastOffset = ऑफसेट;
     }

     जोड़ें (DWORD) (streamOffsets.size () - 1));
   }
 } 

संदेश V509 चेतावनी देता है कि यदि अपवाद से निपटने के दौरान CCacheFileOutBuffer ऑब्जेक्ट नष्ट हो जाता है, तो नया अपवाद तत्काल प्रोग्राम क्रैश हो जाएगा।

स्थिति 12

एक और तुलना जिसका कोई मतलब नहीं है।



V547 एक्सप्रेशन 'endRevision <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Cachelogquery.cpp 999

  typedef index_t revision_t;
 ...
 शून्य CCacheLogQuery :: InternalLog (
    revision_t startRevision
  , संशोधन_टी एंड रीविजन
  , CD CDBBTTPP और startPath का चयन करें
  , int सीमा
  , const CLogOptions और विकल्प)
 {
   ...
   // हम संशोधित <0 के लिए लॉग प्राप्त नहीं कर सकते हैं
   यदि (अंतिम संशोधन <0)
     endRevision = 0;

   ...
 } 

यहाँ केवल नकारात्मक मूल्य नहीं हो सकते। वैरिएबल एंड रीविजन संशोधन एक अहस्ताक्षरित प्रकार का होता है, और इसलिए हमेशा एंडरिविजन> = 0. संभावित परेशानी यह है कि अगर कहीं नकारात्मक मूल्य एक अहस्ताक्षरित प्रकार में बदल गया, तो हम बहुत बड़ी संख्या के साथ काम करना शुरू कर देंगे। इसके लिए, कोई सत्यापन नहीं है।

स्थिति 13

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



दूसरे स्तर पर देखते हैं। हमें कॉपी-पेस्ट तकनीक के उपयोग से संबंधित एक दिलचस्प त्रुटि मिलेगी। वैसे, तीसरे स्तर पर कुछ भी दिलचस्प नहीं था, इसलिए यह व्यर्थ नहीं है कि हम इसे डिफ़ॉल्ट रूप से बंद कर दें।



V524 यह विचित्र है कि 'GetDbgHelpVersion' फ़ंक्शन 'GetImageHlpVersion' फ़ंक्शन (SymbolEngine.h, लाइन 98) के बराबर है। सिंबांगाइन। एच। १०५

  BOOL GetImageHlpVersion (DWORD और dwMS, DWORD और dwLS)
 {
   वापसी (GetInMemoryFileVersion (("DBGHELP.DLL"),
                                 dwMS,
                                 dwLS));
 }

 BOOL GetDbgHelpVersion (DWORD और dwMS, DWORD और dwLS)
 {
   वापसी (GetInMemoryFileVersion (("DBGHELP.DLL"),
                                 dwMS,
                                 dwLS));
 } 

संदेश V524 जारी किया जाता है अगर दो संदिग्ध समान कार्यों का पता लगाया जाता है। सबसे अधिक संभावना है, पहले फ़ंक्शन को फ़ाइल का संस्करण "imagehlp.dll" प्राप्त करना चाहिए, और "dbghelp.dll" बिल्कुल नहीं।

चरण 8

अब पाया त्रुटियों को ठीक किया जाना चाहिए। यह चरण समझ में आता है और हम इसे छोड़ देंगे।



मिली त्रुटियों के लिए, हम उन्हें TortoiseSVN के डेवलपर्स को रिपोर्ट करेंगे।

चरण 9

अब झूठी सकारात्मक के बारे में बात करते हैं। यहाँ स्पष्ट करने के लिए कुछ उदाहरण दिए गए हैं कि एक झूठी सकारात्मक क्या है और उनसे कैसे निपटें।



पहला झूठा सकारात्मक। पीवीएस-स्टूडियो मेमोरी को कॉपी करने वाले गेम को समझ नहीं पाया।



V512 'मेमसीपी' फंक्शन के कॉल से बफर ओवरफ्लो या अंडरफ्लो हो जाएगा। resmodule.cpp 838

  const WORD *
 CResModule :: CountMemReplaceMenuExResource (....)
 {
   ...
   अगर (newMenu! = NULL) {
     CopyMemory (& newMenu [* wordcount], p0, 7 * sizeof (WORD));
   }
    ...
 } 

चेतावनी V512 को इंगित करना चाहिए कि बफर पूरी तरह से संसाधित नहीं है या इसके विपरीत, हम इसके परे चले गए हैं। अब विश्लेषक यह निर्णय लेने में गलत है कि हम केवल एक प्रकार की वर्ड के साथ काम करेंगे, और हम 7 वस्तुओं की प्रतिलिपि बनाना चाहते हैं।



दूसरा झूठा सकारात्मक। यहां, विश्लेषक का मानना ​​है कि सरणी के केवल भाग को संसाधित किया गया है।



V512 'मेमकैंप' फ़ंक्शन के कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा। sshsha.c 317

  स्थिर int sha1_96_verify (....)
 {
   अहस्ताक्षरित चार सही [20];
   sha1_do_hmac (संभाल, blk, लेन, seq, सही);
   वापसी; मेम्कम्प (सही, blk + लेन, 12);
 } 

दरअसल, 'सही' सरणी के केवल एक हिस्से की तुलना की जाती है, लेकिन इसका उद्देश्य यही था।



तीसरा उदाहरण एक गलत सकारात्मक है।



V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। ट्री 234.c 195

  स्थिर शून्य * add234_internal (....)
 {
   ...
   अगर ((c = t-> cmp (e, n-> एलम्स [0])) <0)
     संतान = 0;
   और यदि (c == 0)
     वापसी n-> हाथी [0];  / * पहले से मौजूद है * /
   और अगर (n-> एलम्स [1] == NULL
        ||  (c = t-> cmp (ई, एन-> एलम्स [1])) <0)
          सन्तान = 1;
   और यदि (c == 0)
     वापसी n-> हाथी [1];  / * पहले से मौजूद है * /
   और अगर (n-> एलम्स [2] == NULL
        ||  (c = t-> cmp (ई, एन-> एलम्स [2])) <0)
          संतान = 2;
   और यदि (c == 0)
     वापसी n-> हाथी [2];  / * पहले से मौजूद है * /
   अन्यथा
     संतान = 3;
   ... 

विश्लेषक को यह तथ्य पसंद नहीं है कि चेक 'c == 0' कई बार मौजूद होता है। कोड सही है, क्योंकि चर 'c' अन्य स्थितियों के अंदर बदलता है "c = t-> cmp (e, n-> elems [2])"। हालाँकि, यह एक दुर्लभ स्थिति है। अधिक बार, V517 संदेश कोड में वास्तविक दोषों को इंगित करता है।



अन्य झूठी सकारात्मक पर विचार नहीं किया जाएगा, क्योंकि वे दिलचस्प नहीं हैं। प्रोग्रामर के लिए यह समझना काफी आसान है कि वे झूठे हैं और आपको उन पर ज्यादा ध्यान नहीं देना चाहिए।



झूठी सकारात्मकता से निपटने के कई तरीके हैं:



1) आप कोड को फिर से लिख सकते हैं। यह कभी-कभी काफी उचित होता है। Refactoring एक झूठे सकारात्मक के साथ अंतिम उदाहरण को चोट नहीं पहुंचाती है (हम add234_internal फ़ंक्शन और चेतावनी V517 के बारे में बात कर रहे हैं)।



2) आप सेटिंग्स में कुछ चेक को अक्षम कर सकते हैं, जो आपकी परियोजनाओं में हमेशा एक झूठी सकारात्मक देता है। डिस्कनेक्ट करने के बाद, ये सभी संदेश तुरंत टेबल से गायब हो जाएंगे। यहाँ अधिक विवरण: " सेटिंग्स: पता लगाने योग्य त्रुटियाँ "।



3) यदि झूठी सकारात्मकता कोड से संबंधित है जो जाँचने योग्य नहीं है, तो आप अलग-अलग फ़ाइलों या फ़ोल्डरों को बाहर कर सकते हैं। आप मास्क का उपयोग कर सकते हैं। यहाँ और अधिक पढ़ें " सेटिंग्स: फ़ाइलों की जाँच न करें "। यह तीसरे पक्ष के पुस्तकालयों को विश्लेषण से बाहर करने के लिए सुविधाजनक है।



4) आप विशिष्ट पाठ वाले संदेशों को दबाने के लिए तंत्र का उपयोग कर सकते हैं। यहाँ अधिक विवरण: " सेटिंग्स: संदेश दमन "।



5) ऐसी परिस्थितियां हैं जब एक विशिष्ट चेतावनी को दबा दिया जाना चाहिए। इस स्थिति में, आप "गलत अलार्म के रूप में चिह्नित करें" फ़ंक्शन का उपयोग कर सकते हैं। इस स्थिति में, फ़ॉर्म की एक छोटी टिप्पणी: "// - V त्रुटि कोड" कोड में डाली गई है। इस तरह से चिह्नित कोड अनुभाग त्रुटि सूची में छिपाए जा सकते हैं। ऐसा करने के लिए, एफए बटन का उपयोग करें, जो चिह्नित संदेशों के प्रदर्शन को चालू / बंद करता है। यहां और पढ़ें: झूठी चेतावनियों को दबाएं



ध्यान देने के लिए आप सभी का धन्यवाद। पीवीएस-स्टूडियो की कोशिश करो। हमें अपनी प्रतिक्रिया भेजें। प्रश्न पूछें। यदि आपको कुछ रोचक लगे तो उदाहरण दिखाएं। कार्यान्वयन के लिए नए नैदानिक ​​नियम सुझाएं।



साभार, एंड्री कार्पोव, पीवीएस-स्टूडियो के डेवलपर्स में से एक।

आप प्रतिक्रिया पृष्ठ का उपयोग करके हमसे संपर्क कर सकते हैं।

या ई-मेल द्वारा: support [@] viva64.com, karpov [@] viva64.com।



हमें ईमेल करें, हमारे पास बहुत समर्थन है। मैं व्यक्तिगत रूप से, लेख के लेखक, संचार में भाग लूंगा, और एक सार मानव रोबोट नहीं, जैसा कि ज्यादातर कंपनियों में होता है।