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

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

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

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

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

पहला उदाहरण 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- स्टूडियो तुरंत एक चेतावनी देगा:

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 पर भेजा जाता है, तो यह फ़ंक्शन के बॉडी में डीरेफर किया जाएगा। परिणाम दु: खद और अप्रत्याशित है ।

नल पॉइंटर डेरेफेरिंग सबसे आम पैटर्न में से एक है जिसके बारे में हमें बताया गया है: “यह एक महत्वपूर्ण त्रुटि नहीं है। ठीक है, वह कोड में रहती है और रहती है, और यदि डेरेफेरिंग होती है, तो कार्यक्रम चुपचाप दुर्घटनाग्रस्त हो जाएगा और यह सब हो जाएगा। ” सी ++ प्रोग्रामर से यह सुनना अजीब और दुखद है, लेकिन जीवन जीवन है।

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

यदि प्रोजेक्ट डेवलपर ने PVS-Studio का उपयोग किया है, तो वह अपने कोड की जांच करने और ढाई महीने पहले एक चेतावनी का पता लगाने में सक्षम होगा (जो कि त्रुटि की शुरुआत के बाद कितना बीत चुका है):

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

इस प्रकार, त्रुटि को इसके स्वरूप के समय भी समाप्त कर दिया जाएगा, जो समय की बचत करेगा और संभवतः, डेवलपर की नसों को :)।

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

सही कोड:

 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 " एक्सप्रेशन को बदल देता है। प्रोग्रामर को उम्मीद है कि 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

मैंने अभिव्यक्ति " physical_addr_t pa = (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 सबसे महत्वपूर्ण बिट्स में कम से कम एक गैर- अक्षीय मान होगा। इस चर में बाईं पारी ऑपरेशन को लागू करने के बाद, ये महत्वपूर्ण बिट खो जाएंगे, जिसके परिणामस्वरूप गलत जानकारी एक्स को लिखी जाएगी।

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

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

तब pa हमेशा सही मान लिखेगा।

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

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

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