उदाहरण के रूप में WinMerge का उपयोग करके स्रोत कोड का स्थैतिक विश्लेषण

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





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



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



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



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



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



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



स्रोत कोड के स्थैतिक विश्लेषण के बारे में बहुत सारे शब्द कहे गए थे। अब अभ्यास पर ध्यान देने का समय है। मैं C ++ में लिखा गया एक आवेदन लूंगा और उसमें त्रुटियां खोजने का प्रयास करूंगा।



मैं कुछ छोटा और प्रसिद्ध चुनना चाहता था। चूंकि मैं कई साधनों का उपयोग नहीं करता हूं, तो प्रारंभ मेनू में कार्यक्रमों की सूची के माध्यम से फ़्लिप करना, मेरी पसंद WinMerge तक सीमित थी। WinMerge सोर्स , छोटी (लगभग 186,000 लाइन्स) में उपलब्ध है। कार्यक्रम पर्याप्त गुणवत्ता का है। मैं इस आधार पर बोलता हूं कि मैं इसे त्रुटिपूर्ण रूप से उपयोग करता हूं, और स्रोत कोड का 25% टिप्पणियों (एक अच्छा संकेत) द्वारा कब्जा कर लिया गया है। सामान्य तौर पर, सबसे अच्छा विकल्प।



नवीनतम उपलब्ध संस्करण 2.13.20 (दिनांक 10/20/2010) डाउनलोड किया गया था। विश्लेषण के लिए, मैंने एक सामान्य-उद्देश्य विश्लेषक के प्रोटोटाइप का उपयोग किया जिसे हम विकसित कर रहे हैं। मैं इस पर अधिक विस्तार से ध्यान दूंगा।



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



इसलिए, यहां कुछ दिलचस्प बिंदु हैं जो मुझे WinMerge के 2.13.20 के स्रोत कोड में आधे घंटे (15 मिनट सत्यापन, परिणाम देखने के 15 मिनट) के भीतर मिले। अन्य संदिग्ध स्थान हैं, लेकिन यह पता लगाना कि क्या वास्तव में कोई गलती है या नहीं। अब मुझे एक परियोजना में अधिक से अधिक दोष खोजने में कोई समस्या नहीं है। मैं इनायत से दिखाना चाहता हूं कि स्थैतिक विश्लेषण कितना उपयोगी है और कैसे एक सरसरी अध्ययन भी कई त्रुटियों की पहचान कर सकता है।



पहला उदाहरण। विश्लेषक ने मुझे कुछ त्रुटियों की ओर इशारा किया "V530 - फ़ंक्शन 'फू' के वापसी मूल्य का उपयोग करने की आवश्यकता है।" आमतौर पर, ये चेतावनी कार्यों के दुरुपयोग के कारण होती है। कोड के एक टुकड़े पर विचार करें:

  / **
 * @ दुख निर्दिष्ट आइटम के लिए दोनों पक्षों पर फ़ाइल नाम प्राप्त करें।
 यदि आइटम विशेष आइटम है, तो @note खाली स्ट्रिंग लौटें।
 * /
 शून्य CDirView :: GetItemFileNames (int sel,
   स्ट्रिंग और strLeft, स्ट्रिंग और strRight) कास्ट
 {
   UINT_PTR diffpos = GetItemKey (sel);
   अगर (diffpos == (UINT_PTR) SPECIAL_ITEM_POS)
   {
     strLeft.empty ();
     strRight.empty ();
   }
   अन्यथा
   {
      ...
   }
 } 

फ़ंक्शन को एक निश्चित स्थिति में दो खाली लाइनों को वापस करना चाहिए। हालाँकि, लापरवाही से, std :: string :: खाली () फ़ंक्शन को std के बजाय कहा जाता है :: string :: clear ()। यह, संयोग से, यह एक दुर्लभ गलती नहीं है जितना कि यह प्रतीत हो सकता है। मैं उनसे कई अन्य परियोजनाओं में मिला। सहित यह एक और WinMerge फ़ंक्शन में है:

  / **
 * @ दुख का स्पष्ट संस्करण का मान (डिफ़ॉल्ट पर रीसेट)।
 * /
 शून्य VariantValue :: साफ़ ()
 {
   m_vtype = VT_NULL;
   m_bvalue = false;
   m_ivalue = 0;
   m_fvalue = 0;
   m_svalue.empty ();
   m_tvalue = 0;
 } 

यहाँ फिर से, अपेक्षित लाइन समाशोधन नहीं होता है।



लेकिन चेतावनी "V501 - बाईं और दाईं ओर समान उप-अभिव्यक्तियाँ हैं" || ऑपरेटर ":

  BUFFERTYPE m_nBufferType [2];
 ...
 // अनाम बफ़र्स संभालें
 अगर ((m_nBufferType [nBuffer] == BUFFER_UNNAMED) ||
     (m_nBufferType [nBuffer] == BUFFER_UNNAMED))
   nSaveErrorCode = SAVE_NO_FILENAME; 

यदि आप पास के कोड को देखते हैं, तो सादृश्य द्वारा इसे पढ़ना चाहिए:

  (m_nBufferType [0] == BUFFER_UNNAMED) ||
 (m_nBufferType [1] == BUFFER_UNNAMED) 

और अगर नहीं है, तो अभी भी किसी प्रकार की त्रुटि है।



यदि विभिन्न आपात स्थिति होती है, तो WinMerge त्रुटियों की रिपोर्ट करने का प्रयास करेगा, लेकिन कई मामलों में यह विफल हो जाएगा। यह, वैसे, एक अच्छा उदाहरण है कि कैसे एक कोड विश्लेषक प्रोग्राम के शायद ही कभी इस्तेमाल किए गए हिस्सों में त्रुटियों का पता लगा सकता है। कोड में कई त्रुटियां हैं, जो पीवीएस-स्टूडियो रिपोर्ट इस प्रकार है: "V510 - 'प्रारूप' फ़ंक्शन को वर्ग-प्रकार के चर को 'एन' वास्तविक तर्क के रूप में प्राप्त करने की उम्मीद नहीं है। कोड उदाहरण:

  स्ट्रिंग GetSysError (int nerr);
 ...
 CString संदेश;
 msg.Format (
 _T ("रजिस्ट्री कुंजी खोलने में विफल HKCU /% s: \ n \ t% d:% s"),
 f_RegDir, retVal, GetSysError (retVal)); 

पहली नज़र में, सब कुछ ठीक है। यह सिर्फ "स्ट्रिंग" का प्रकार है "std :: wstring" से ज्यादा कुछ नहीं है। इसलिए, सबसे अच्छे मामले में, हम जिबरिश को छापेंगे, और सबसे खराब स्थिति में, एक एक्सेस उल्लंघन की गलती होगी। एक स्ट्रिंग के लिए एक पॉइंटर के बजाय, "std :: wstring" प्रकार का एक ऑब्जेक्ट स्टैक पर धकेल दिया जाता है। मैंने इस स्थिति को " बिग ब्रदर हेल्प्स यू " लेख में अधिक विस्तार से वर्णित किया। सही कोड में c_str () का कॉल होना चाहिए:

  msg.Format (
 _T ("रजिस्ट्री कुंजी खोलने में विफल HKCU /% s: \ n \ t% d:% s"),
 f_RegDir, retVal, GetSysError (retVal) .c_str ()); 

और आगे चलते हैं। यहाँ एक बहुत ही संदिग्ध कोड है। यहाँ कोई गलती है या नहीं, मुझे नहीं पता। लेकिन यह अजीब है कि "यदि" ऑपरेटर की दो शाखाओं में पूरी तरह समान कोड है। विश्लेषक ने इस स्थिति के बारे में नैदानिक ​​संदेश "वी 532 - द '' स्टेटमेंट '' स्टेटमेंट" के बराबर है। यहाँ यह इस संदिग्ध कोड है:

  यदि (अधिकतम <INT_MAX)
 {
   के लिए (i = min? i <max; i ++)
   {
     if (eptr> = md-> end_subject ||
         IS_NEWLINE (eptr)
       तोड़;
     eptr ++;
     जबकि (eptr <md-> end_subject &&
            (* eptr & 0xc0) == 0x80)
       eptr ++;
     }
   }
 अन्यथा
 {
   के लिए (i = min? i <max; i ++)
   {
     if (eptr> = md-> end_subject ||
         IS_NEWLINE (eptr)
       तोड़;
     eptr ++;
     जबकि (eptr <md-> end_subject &&
            (* eptr & 0xc0) == 0x80)
       eptr ++;
     }
   }
 } 

मुझे लगता है कि यहाँ क्या है: "यह अच्छी तरह से, अच्छा कारण है।"



खैर, एक और उदाहरण और खत्म, शायद। विश्लेषक ने एक संदिग्ध चक्र पाया: "V534 - यह संभावना है कि 'के लिए' ऑपरेटर के अंदर एक गलत चर की तुलना की जा रही है। 'I' की समीक्षा करने पर विचार करें। "सोर्स कोड:

  // पाठ से बाइट्स के अनुवादित सरणी की लंबाई प्राप्त करें।
 int Text2BinTranslator :: iLengthOfTransToBin (
   चार * src, int srclen)
 {
   ...
     के लिए (k = i; i <srclen; k ++)
     {
       अगर (src [k] == '>')
         तोड़;
     }
   ...
 } 

यह कोड Access Violation के लिए पूर्वनिर्धारित है। लूप को तब तक जारी रखना चाहिए जब तक कि '>' वर्ण नहीं मिलता है या 'srclen' वर्ण की लंबाई के साथ एक स्ट्रिंग समाप्त हो जाती है। यह सिर्फ इस संयोग से है कि चर 'i' का उपयोग तुलना के लिए किया गया था, न कि 'k'। यदि '>' चरित्र नहीं मिला, तो शायद सब कुछ दुख की बात है।

निष्कर्ष

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