स्थिर कोड विश्लेषण में त्रुटियां नहीं पाई जाती हैं क्योंकि इसका उपयोग नहीं किया जाता है

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

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

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

क्या होगा यदि बग को जल्द से जल्द चरण में पकड़ा गया था? इसका उत्तर सरल है: प्रोग्रामर को इसके लिए खुद को दिखाने के लिए इंतजार नहीं करना होगा, फिर दोषपूर्ण कोड को खोजें और सही करें।

आइए उन त्रुटियों को देखें जिन्हें पीवीएस-स्टूडियो तुरंत पता लगा सकता था:

पहला उदाहरण SatisfactoryModLoader परियोजना से लिया गया है। त्रुटि को ठीक करने से पहले, कोड निम्नानुसार देखा गया:

// gets an API function from the mod handler SML_API PVOID getAPIFunction(std::string name) { bool found = false; for (Registry reg : modHandler.APIRegistry) { if (reg.name == name) { found = true; } } if (!found) { std::string msg = ...; MessageBoxA(NULL, msg.c_str(), "SatisfactoryModLoader Fatal Error", MB_ICONERROR); abort(); } } 

इस कोड में एक त्रुटि थी, कि PVS-Studio तुरंत एक चेतावनी जारी करेगा:

V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। ModFunctions.cpp 44

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

 // gets an API function from the mod handler SML_API PVOID getAPIFunction(std::string name) { bool found = false; PVOID func = NULL; for (Registry reg : modHandler.APIRegistry) { if (reg.name == name) { func = reg.func; found = true; } } if (!found) { std::string msg = ...; MessageBoxA(NULL, msg.c_str(), "SatisfactoryModLoader Fatal Error", MB_ICONERROR); abort(); } return func; } 

उत्सुकतावश, लेखक ने बग को महत्वपूर्ण के रूप में चिह्नित किया: " फिक्स्ड क्रिटिकल बग जहां एपीआई फ़ंक्शन वापस नहीं किया गया था "।

Mc6809 परियोजना इतिहास से दूसरी प्रतिबद्धताओं में, निम्नलिखित कोड में संपादन शुरू किए गए थे:

 void mc6809dis_direct( mc6809dis__t *const dis, mc6809__t *const cpu, const char *const op, const bool b16 ) { assert(dis != NULL); assert(op != NULL); addr.b[MSB] = cpu->dp; addr.b[LSB] = (*dis->read)(dis, dis->next++); ... if (cpu != NULL) { ... } } 

लेखक ने केवल एक पंक्ति को सुधारा। उसने अभिव्यक्ति की जगह ले ली

 addr.b[MSB] = cpu->dp; 

निम्नलिखित एक के लिए

 addr.b[MSB] = cpu != NULL ? cpu->dp : 0; 

पुराने कोड संस्करण में अशक्त सूचक के लिए कोई जांच नहीं थी। यदि ऐसा होता है कि null पॉइंटर को mc6809dis_direct फ़ंक्शन को दूसरे तर्क के रूप में पास किया जाता है, तो इसका डीरेक्शन फ़ंक्शन के शरीर में होगा। परिणाम दु: खद और अप्रत्याशित है ।

नल पॉइंटर डेरेफेरेंस सबसे सामान्य पैटर्न में से एक है जिसके बारे में हमें बताया गया है: "यह एक महत्वपूर्ण बग नहीं है। कौन परवाह करता है कि यह कोड में संपन्न है? यदि कोई गड़बड़ी होती है, तो कार्यक्रम चुपचाप दुर्घटनाग्रस्त हो जाएगा और यह बात है। C ++ प्रोग्रामर से यह सुनना अजीब और दुखद है, लेकिन जीवन ऐसा होता है।

वैसे भी, इस परियोजना में इस तरह के संबंध एक बग में बदल गए हैं, जैसा कि कमिट का विषय हमें बताता है: " बग फिक्स --- एनएएलडी डिफरेंस "।

यदि प्रोजेक्ट डेवलपर ने पीवीएस-स्टूडियो का उपयोग किया था, तो वह ढाई महीने पहले चेतावनी की जांच कर सकता था। यह तब है जब बग को पेश किया गया था। यहाँ चेतावनी है:

N5ptr के खिलाफ सत्यापित होने से पहले V595 'cpu' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 1814, 1821. mc6809dis.c 1814

इस प्रकार, बग की उपस्थिति के समय तय किया गया होगा, जिसने डेवलपर के समय और नसों को बचाया होगा :)।

लिबमॉर्टन प्रोजेक्ट में एक और दिलचस्प सुधार का उदाहरण मिला।

कोड तय किया जाना है:

 template<typename morton> inline bool findFirstSetBitZeroIdx(const morton x, unsigned long* firstbit_location) { #if _MSC_VER && !_WIN64 // 32 BIT on 32 BIT if (sizeof(morton) <= 4) { return _BitScanReverse(firstbit_location, x) != 0; } // 64 BIT on 32 BIT else { *firstbit_location = 0; if (_BitScanReverse(firstbit_location, (x >> 32))) { // check first part firstbit_location += 32; return true; } return _BitScanReverse(firstbit_location, (x & 0xFFFFFFFF)) != 0; } #elif _MSC_VER && _WIN64 .... #elif __GNUC__ .... #endif } 

अपने संपादन में, एक प्रोग्रामर " * फर्स्टबिट_लोकेशन + 32 " के साथ " फर्स्टबिट_लोकेशन + = 32 " एक्सप्रेशन को बदल देता है। प्रोग्रामर को उम्मीद थी कि पहले vbit_location पॉइंटर द्वारा संदर्भित वेरिएबल के मान में 32 जोड़ा जाएगा, लेकिन 32 को पॉइंटर में ही जोड़ा गया। पॉइंटर के बदले हुए मूल्य का उपयोग कहीं भी नहीं किया गया और अपेक्षित परिवर्तनीय मूल्य अपरिवर्तित रहे।

पीवीएस-स्टूडियो इस कोड के लिए चेतावनी जारी करेगा:

V1001 'Firstbit_location' चर को असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। morton_common.h 22

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

इसके अलावा, यह पता चला कि यह त्रुटि इतनी आसान नहीं थी! न केवल फ़ाइल बनाने के बाद से यह कार्यक्रम में है, बल्कि इसने पड़ोसी लाइनों में कई संपादन का भी अनुभव किया है और इस परियोजना में 3 (!) वर्षों तक मौजूद है! इस समय कार्यक्रम का तर्क टूट गया था, और यह डेवलपर्स के अपेक्षित तरीके से काम नहीं कर रहा था। यदि उन्होंने पीवीएस-स्टूडियो का इस्तेमाल किया होता, तो बग का पता काफी पहले चल जाता।

अंत में, आइए एक और अच्छा उदाहरण देखें। जब मैं GitHub पर बग फिक्स एकत्र कर रहा था, मैं कई बार निम्नलिखित सामग्री के साथ एक फिक्स पर आया। निश्चित त्रुटि यहाँ थी:

 int kvm_arch_prepare_memory_region(...) { ... do { struct vm_area_struct *vma = find_vma(current->mm, hva); hva_t vm_start, vm_end; ... if (vma->vm_flags & VM_PFNMAP) { ... phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + vm_start - vma->vm_start; ... } ... } while (hva < reg_end); ... } 

PVS-Studio ने इस कोड स्निपेट के लिए चेतावनी जारी की:

V629 'vma-> vm_pgoff << 12' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। mmu.c 1795

मैंने " भौतिक_दाद्र_त पा = = (vma-> vm_pgoff << PAGE_SHIFT) + vm_start - vma-> vm_start; "

 void foo(unsigned long a, unsigned long b) { unsigned long long x = (a << 12) + b; } 

यदि 32-बिट चर का मान 0xFFFFF से अधिक है, तो 12 उच्चतम बिट्स में कम से कम एक नॉनबेल मान होगा। इस चर को छोड़ देने के बाद, ये महत्वपूर्ण बिट खो जाएंगे, जिसके परिणामस्वरूप x में गलत जानकारी लिखी गई है ।

उच्च बिट्स के नुकसान को खत्म करने के लिए, हमें पहले एक लंबे समय तक टाइप किए गए को कास्ट करने की आवश्यकता होती है और इसके बाद ही परिवर्तनशील होता है:

 pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT; pa += vm_start - vma->vm_start; 

इस तरह, एक सही मान हमेशा पा में लिखा जाएगा ।

यह ठीक होगा, लेकिन यह बग, लेख से पहला उदाहरण भी महत्वपूर्ण है। यह लेखक ने टिप्पणी में इसके बारे में लिखा है। इसके अलावा, इस त्रुटि ने बड़ी संख्या में परियोजनाओं के लिए अपना रास्ता ढूंढ लिया। त्रासदी के पैमाने की पूरी तरह से सराहना करने के लिए, मैं GitHub पर इस बगफिक्स की खोज करते समय परिणामों की संख्या को देखने का सुझाव देता हूं। डरावना, है ना?

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