संकलक और चयनित उपकरण द्वारा कोड विश्लेषण के दृष्टिकोण में अंतर

कंपाइलर और थर्ड-पार्टी स्टैटिक कोड एनालिसिस टूल्स का एक सामान्य काम है - खतरनाक कोड अंशों की पहचान करना। हालाँकि, उनके विश्लेषण के प्रकार में महत्वपूर्ण अंतर है। मैं Intel C ++ कंपाइलर और PVS-Studio विश्लेषक के उदाहरणों का उपयोग करके दृष्टिकोणों में अंतर प्रदर्शित करने का प्रयास करूँगा और समझाऊंगा कि उनके कारण क्या थे।



इस बार, नोटपैड ++ संस्करण 5.8.2 एक परीक्षण विषय के रूप में कार्य करेगा।

नोटपैड ++

पहले चयनित परियोजना के बारे में। नोटपैड ++ एक स्वतंत्र और मुफ्त स्रोत कोड संपादक है जो बड़ी संख्या में भाषाओं का समर्थन करता है, साथ ही मानक नोटपैड के लिए प्रतिस्थापन भी करता है। यह माइक्रोसॉफ्ट विंडोज पर चलता है और जीपीएल के तहत जारी किया गया है। मुझे प्रोजेक्ट पसंद आया क्योंकि यह C ++ में लिखा गया है और इसका आकार छोटा है - कोड की 73,000 लाइनें। और सबसे महत्वपूर्ण बात, यह एक काफी सटीक परियोजना है, जैसा कि प्रोजेक्ट सेटिंग्स में / W4 स्विच और / WX स्विच द्वारा इंगित किया गया है, जो प्रत्येक चेतावनी को एक त्रुटि के रूप में माना जाता है।

संकलक में स्थैतिक विश्लेषण

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



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



इस दृष्टिकोण का परिणाम चेतावनियों का "इलाका" है। संकलक जानबूझकर विभिन्न संरचनाओं पर बचाता है जो उच्च-स्तरीय त्रुटियों का पता लगाने में मदद कर सकते हैं। आइए देखते हैं कि नोटपैड ++ प्रोजेक्ट के लिए इंटेल सी + + क्या स्थानीय चेतावनी उत्पन्न करेगा। आपको याद दिला दूं कि नोटपैड ++ प्रोजेक्ट को विजुअल C ++ कंपाइलर द्वारा / W4 स्विच के साथ चेतावनी के बिना संकलित किया गया है। इंटेल C ++ कंपाइलर स्वाभाविक रूप से चेतावनी का एक अलग सेट होगा, और मैं एक विशिष्ट स्विच / W5 [इंटेल C ++] भी सेट करता हूं। इसके अलावा, मैं इंटेल C ++ कंपाइलर को "टिप्पणी" क्या कहता हूं, इस पर एक नज़र डालूंगा।



आइए देखें कि हमें इंटेल C ++ से किस तरह के संदेश मिले। इसलिए उन्होंने चारुपर फ़ंक्शन के साथ काम करते समय एक ही प्रकार की चार त्रुटियां पाईं (लेख के अंत में नोट देखें)। इस त्रुटि के निदान के "इलाके" पर ध्यान दें - बस एक अत्यंत खतरनाक प्रकार का रूपांतरण पाया गया। संबंधित कोड टुकड़े पर विचार करें:

  wchar_t * destStr = new wchar_t [len + 1];
 ...
 for (int j = 0; j <nbChar; j ++)
 {
   अगर (केस == उत्तर प्रदेश)
     destStr [j] =
       (wchar_t) :: CharUpperW ((LPWSTR) destStr [j]);
   अन्यथा
     destStr [j] =
       (wchar_t) :: CharLowerW ((LPWSTR) destStr [j]);
 } 

अजीब प्रकार के रूपांतरण हैं। इंटेल C ++ कंपाइलर रिपोर्ट: "# 810:" LPWSTR = {WCHAR = {__ wchar_t} *} "से" __wchar_t "रूपांतरण महत्वपूर्ण बिट्स खो सकता है। चलो चार्यूपर फ़ंक्शन के प्रोटोटाइप को देखें।

  LPTSTR WINAPI चार्यूपर (
   __in LPTSTR lpsz
 ); 

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



लेकिन सच्चाई यह है कि इंटेल सी ++ द्वारा खोजे गए भयावहता शायद वहीं समाप्त हो जाती है। बाकी सब कुछ बहुत अधिक उबाऊ है और कोड की तुलना में मैला कोड होने की अधिक संभावना है जो एक त्रुटि का कारण होगा। लेकिन फिर भी कुछ अन्य चेतावनियों पर विचार करें।



बड़ी संख्या में # 1125 संदेश जारी किए गए:



"# 1125: फ़ंक्शन" विंडो :: init (HINSTANCE, HWND) "" TabBarPlus :: init "द्वारा छिपा हुआ है - आभासी फ़ंक्शन का उद्देश्य क्या है?"



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



निम्न उदाहरण। संदेश "# 186: शून्य के साथ अहस्ताक्षरित पूर्णांक की निरर्थक तुलना" निरर्थक तुलना के लिए जारी किया गया है:

  स्थिर LRESULT कॉलबैक हुकप्रेमहाउस (
   UINT nCode, WPARAM wParam, LPARAM lParam)
 {
   अगर (nCode <0)
   {
     ...
     वापसी 0;
   }
 ...
 } 

"NCode <0" की स्थिति हमेशा झूठी होती है। एक अच्छा स्थानीय निदान का एक अच्छा उदाहरण। इसलिए त्रुटि का पता लगाना काफी संभव है।



नवीनतम इंटेल C ++ चेतावनी पर विचार करें और यह पर्याप्त है। मुझे लगता है कि "इलाके" का विचार पहले से ही स्पष्ट है।

  शून्य ScintillaKeyMap :: showCurrentSettings () {
   int i = :: SendDlgItemMessage (...);
   ...
   for (size_t i = 0; मैं <nrKeys; i ++)
   {
     ...
   }
 } 

यहाँ फिर से, कोई गलती नहीं है, बस बहुत सफल चर नामकरण नहीं है। प्रारंभ में, चर "i" प्रकार "int" का है। फिर, एक नया वैरिएबल "i" टाइप "size_t" को "for ()" स्टेटमेंट में घोषित किया जाता है और अन्य उद्देश्यों के लिए उपयोग किया जाता है। "Size_t i" की घोषणा के समय संकलक जानता है कि एक ही नाम के साथ पहले से ही एक चर है और एक चेतावनी जारी करता है। फिर, इसके लिए कंपाइलर को किसी भी अतिरिक्त डेटा को स्टोर करने की आवश्यकता नहीं थी। उसे अभी भी याद रखना चाहिए कि फ़ंक्शन के शरीर के अंत तक, चर "int i" उपलब्ध है।

बाहरी स्टेटिक कोड एनालाइजर

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



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



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



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

  बूल _isPointXValid;
 बूल _isPointYValid;
 बूल .PointValid () {
   वापसी _isPointXValid && _isPointXValid;
 }; 

PVS-Studio विश्लेषक रिपोर्ट करता है: "V501: बाईं और 'दाईं ओर' ऑपरेटर के समान उप-अभिव्यक्तियाँ हैं: _isPointXValid && _isPointXValid।"



मुझे लगता है कि त्रुटि का सार स्पष्ट है, और हम इस पर अधिक विस्तार से ध्यान नहीं देंगे। निदान "स्थानीय" है, क्योंकि सत्यापन एकल अभिव्यक्ति का विश्लेषण करने की प्रक्रिया में किया जा सकता है।



_ContMap सरणी के अपूर्ण समाशोधन की ओर अग्रसर एक और स्थानीय त्रुटि:

  #define CONT_MAP_MAX 50
 int _iContMap [CONT_MAP_MAX];
 ...
 DockingManager :: DockingManager ()
 {
   ...
   मेमसेट (_ContMap, -1, CONT_MAP_MAX);
   ...
 } 

चेतावनी "V512: मेमसेट फ़ंक्शन के कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा" जारी किया जाता है। कोड का सही संस्करण:

  मेमसेट (_iContMap, -1, CONT_MAP_MAX * sizeof (int)); 

और अब अधिक दिलचस्प चीजों पर चलते हैं। एक कोड जहां आपको एक साथ दो शाखाओं का विश्लेषण करने की आवश्यकता होती है ताकि कुछ पर संदेह किया जा सके।

  शून्य TabBarPlus :: drawItem (
   DRAWITEMSTRUCT * pDrawItemStruct)
 {
 ...

   अगर (_isVertical)
     झंडे | = DT_BOTTOM;
   अन्यथा
     झंडे | = DT_BOTTOM;
 ...
 } 

PVS-Studio यहां रिपोर्ट करता है: "V523: 'तत्कालीन' कथन 'अन्य' कथन के बराबर है।" यदि आप पड़ोस में कोड को देखते हैं, तो हम यह निष्कर्ष निकाल सकते हैं कि वास्तव में लेखक इस तरह से लिखना चाहता था:

  अगर (_isVertical)
   झंडे | = DT_VCENTER;
 अन्यथा
   झंडे | = DT_BOTTOM;

अब हिम्मत रखो। आपको निम्नलिखित कोड के टुकड़े के रूप में परीक्षण किया जाएगा:

  शून्य KeyScriptStyleDialog :: updateDlg () 
 {
   ...
   शैली और w1Style =
     _pUserLang -> _ styleArray.getStyler (STYLE_WORD1_INDEX);
   styleUpdate (w1Style, _pFgColour [0], _pBgColour [0],
     IDC_KEYWORD1_FONT_COMBO, IDC_KEYWORD1_FONTSIZE.COMBO,
     IDC_KEYWORD1_BOLD_CHECK, IDC_KEYWORD1_ITALIC_CHECK,
     IDC_KEYWORD1_UNDERLINE_CHECK);

   शैली और w2Style =
     _pUserLang -> _ styleArray.getStyler (STYLE_WORD2_INDEX);
   styleUpdate (w2Style, _pFgColour [1], _pBgColour [1],)
     IDC_KEYWORD2_FONT_COMBO, IDC_KEYWORD2_FONTSIZE.COMBO,
     IDC_KEYWORD2_BOLD_CHECK, IDC_KEYWORD2_ITALIC_CHECK,
     IDC_KEYWORD2_UNDERLINE_CHECK);

   शैली और w3Style =
     _pUserLang -> _ styleArray.getStyler (STYLE_WORD3_INDEX);
   styleUpdate (w3Style, _pFgColour [2], _pBgColour [2],
     IDC_KEYWORD3_FONT_COMBO, IDC_KEYWORD3_FONTSIZE.COMBO,
     IDC_KEYWORD3_BOLD_CHECK, IDC_KEYWORD3_BOLD_CHECK,
     IDC_KEYWORD3_UNDERLINE_CHECK);

   शैली और w4Style =
     _pUserLang -> _ styleArray.getStyler (STYLE_WORD4_INDEX);
   styleUpdate (w4Style, _pFgColour [3], _pBgColour [3],
     IDC_KEYWORD4_FONT_COMBO, IDC_KEYWORD4_FONTSIZE.COMBO,
     IDC_KEYWORD4_BOLD_CHECK, IDC_KEYWORD4_ITALIC_CHECK,
     IDC_KEYWORD4_UNDERLINE_CHECK);
   ...
 } 

हम कह सकते हैं कि मुझे अपने पीवीएस-स्टूडियो विश्लेषक पर गर्व है, जो यहां एक त्रुटि पा सकता है। मुझे लगता है कि आप इसे नोटिस करने की संभावना नहीं रखते हैं और स्पष्टीकरण के इंतजार में, पूरे कोड के टुकड़े को छोड़ देते हैं। ऐसा कोड वस्तुतः समीक्षा (कोड समीक्षा) के लिए असंभव है। लेकिन स्थिर विश्लेषक रोगी और पांडित्य है: "V525: समान ब्लॉकों के संग्रह वाले कोड। आइटम '7', '7', '6', '7' को लाइनों 576, 580, 584, 588 में जांचें।



मैं दिलचस्प को उजागर करने के लिए पाठ को छोटा करूंगा:

  स्टाइलअपडेट (...
   IDC_KEYWORD1_BOLD_CHECK, IDC_KEYWORD1_ITALIC_CHECK,
   ...);
 स्टाइलअपडेट (...
   IDC_KEYWORD2_BOLD_CHECK, IDC_KEYWORD2_ITALIC_CHECK,
   ...);
 स्टाइलअपडेट (...
   IDC_KEYWORD3_BOLD_CHECK, !!  IDC_KEYWORD3_BOLD_CHECK !!
   ...);
 स्टाइलअपडेट (...
   IDC_KEYWORD4_BOLD_CHECK, IDC_KEYWORD4_ITALIC_CHECK, 

कोड की कॉपी-पेस्ट द्वारा सबसे अधिक संभावना थी। परिणाम यह था कि IDC_KEYWORD3_BOLD_CHECK का उपयोग IDC_KEYWORD3_ITALIC_CHECK के बजाय किया गया था। संख्या 7, '7', '6', '7' के बारे में बात करते हुए चेतावनी थोड़ी अजीब लगती है। दुर्भाग्य से, अधिक समझने योग्य संदेश देना मुश्किल है। ये नंबर फॉर्म के मैक्रोज़ से लिए गए हैं:

  #define IDC_KEYWORD1_ITALIC_CHECK (IDC_KEYWORD1 + 7)
 #define IDC_KEYWORD3_BOLD_CHECK (IDC_KEYWORD3 + 6) 

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

कुछ संख्या

आइए हम संकलक के "स्थानीय" विश्लेषण के एक और परिणाम और विशेष उपकरणों में अधिक वैश्विक एक का वर्णन करते हैं। "स्थानीय विश्लेषण" में यह स्पष्ट करना मुश्किल है कि यह स्थिति वास्तव में खतरनाक है या नहीं। नतीजतन, अधिक झूठी सकारात्मकता के परिमाण का क्रम होता है। मैं एक उदाहरण के साथ समझाऊंगा।



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



नोटपैड ++ प्रोजेक्ट का विश्लेषण करते समय, इंटेल सी ++ कंपाइलर ने 439 चेतावनी और 3,139 टिप्पणियां उत्पन्न कीं। मुझे नहीं पता कि उनमें से कितने वास्तव में वास्तविक गलतियों की ओर इशारा करते हैं। जिस चीज में मुझे देखने के लिए पर्याप्त ताकत थी, मैंने चारुपर से संबंधित केवल 4 वास्तविक त्रुटियों को देखा (ऊपर विवरण देखें)।



उनमें से प्रत्येक की सावधानीपूर्वक जांच करने के लिए 3578 संदेश बहुत अधिक हैं। यह पता चलता है कि संकलक कार्यक्रम में प्रत्येक बीसवीं पंक्ति पर ध्यान देने का सुझाव देता है (73000/3578 = 20)। यह गंभीर नहीं है। एक सामान्य-उद्देश्य विश्लेषक के मामले में, यदि संभव हो तो, सभी अनावश्यक को काट दें।



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



- अद्यतन:



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



तथ्य यह है कि CharUpperW एक स्ट्रिंग और व्यक्तिगत पात्रों दोनों के साथ काम कर सकता है। यदि पॉइंटर का ऊपरी हिस्सा शून्य है, तो माना जाता है कि यह पॉइंटर नहीं है, बल्कि एक प्रतीक है। इस पाठ्यक्रम स्थान में जीत एपीआई इसकी वक्रता से दुखी था, लेकिन नोटपैड ++ में कोड सही ढंग से लिखा गया था।



वैसे, अब यह पता चला है कि Intel C ++ को कोई त्रुटि नहीं मिली।