Cppcheck का उपयोग करके C / C ++ स्रोत कोड का विश्लेषण करने की पेचीदगियाँ

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

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

डाउनलोड और स्थापित करें

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

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

लिनक्स के लिए बनाएँ

लिनक्स पर बिल्डिंग बेहद सरल है: डाउनलोड, अनज़िप, निर्देशिका पर जाएं और निष्पादित करें:

unzip cppcheck-master.zip cd cppcheck-master make 

विंडोज के लिए बनाएँ

विंडोज में निर्माण मुश्किल नहीं होना चाहिए - वीएस के लिए एक परियोजना है। खोलो, इकट्ठा करो। मैंने खुद इसकी कोशिश नहीं की है, क्योंकि मुझे ऐसी कोई जरूरत नहीं है।

एक प्लगइन के रूप में कैपचेक

आईडीई के लिए प्लगइन्स के रूप में - कोड :: ब्लॉक, कोडलाइट, गेडिट और एक्लिप्स के लिए निश्चित रूप से प्लगइन्स हैं। लेकिन यह इस तक ही सीमित नहीं है, क्योंकि हर्टसन, जेनकिंस असेंबली फार्म के लिए प्लगइन्स हैं, कछुआ एसवीएन और मर्क्यूरियल वर्जन कंट्रोल सिस्टम के लिए। विजुअल स्टूडियो के लिए कोई प्लगइन नहीं है, लेकिन मुख्य पृष्ठ पर एक बहुत अच्छा वाक्यांश है:

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

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

यह ध्यान देने योग्य है कि cppcheck को GNU GPL के अंतर्गत लाइसेंस प्राप्त है। यह आपको आसानी से इस कार्यक्रम के स्रोत कोड को लेने की अनुमति देता है, इसे अपने गिट रिपॉजिटरी में खींचें और इसे किसी भी जरूरतों के लिए समाप्त करें, अपने स्वयं के नियमों और पुस्तकालयों को जोड़ते हुए।

विश्लेषक सेटअप

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

निष्पक्षता में, मैं ध्यान देता हूं कि नीचे दी गई सभी जानकारी दस्तावेज़ीकरण से या cppcheck --help कमांड चलाकर प्राप्त की जा सकती है, लेकिन मैं सबसे महत्वपूर्ण बारीकियों पर अधिक विस्तार से (और रूसी में) ध्यान केंद्रित करूंगा । Cppcheck प्रलेखन वर्ष-दर-वर्ष बेहतर हो रहा है, इसलिए यह कभी-कभी इसे फिर से पढ़ने के लिए उपयोगी है।

यदि यह मुझे लगता है कि मैं दस्तावेज़ीकरण को वापस लेने में लगा हुआ हूं, तो अगले भाग को पढ़ें, क्योंकि यहां उन लोगों के लिए जानकारी है, जिन्होंने पहले कभी cccheck और analyzers का उपयोग नहीं किया है।

त्रुटि स्तर

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

यह कैसे काम करता है इसका एक उदाहरण। मान लें कि आपको निम्नलिखित कोड का विश्लेषण करने की आवश्यकता है:

 void f() { char *a = malloc(100); process_a(a); } 

पहली नज़र में, एक गलती है: कोई स्वतंत्र नहीं है। हालाँकि, यदि process_a फ़ंक्शन एक लाइब्रेरी फ़ंक्शन है, तो यह निश्चित रूप से कहना असंभव है कि process_a पॉइंटर को कहीं अंदर मुक्त नहीं करता है। अगर वेरिएबल वास्तव में process_a फ़ंक्शन के अंदर मुक्त हो गया है, तो यह एक गलत सकारात्मक है जो विश्लेषण में हस्तक्षेप करेगा। इसलिए, cppcheck पहले प्रोग्राम के कोड में process_a फ़ंक्शन के कार्यान्वयन का पता लगाने की कोशिश करेगा जिसका विश्लेषण किया जा रहा है, सुनिश्चित करें कि यह मुफ्त कॉल नहीं करता है, और केवल इस मामले में एक त्रुटि उत्पन्न करेगा। यदि कोई कार्यान्वयन नहीं मिला है, तो cppcheck संभव सबसे अनुकूल परिदृश्य मानता है: process_a स्मृति को मुक्त करता है और इसलिए त्रुटि नहीं करेगा। हालांकि, लाइब्रेरी के कार्यों को पहचानने के लिए cppcheck को "सिखाया" जा सकता है, जिससे विश्लेषण की सटीकता बढ़ जाएगी - इसके बारे में नीचे चर्चा की जाएगी।

दूसरा उदाहरण:

 void f() { char *a = malloc(100); if(random()) g_exit(0); free(a) } 

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

उदाहरण बताते हैं कि cppcheck पुनर्बीमा है, और पर्याप्तता पट्टी अधिक है। अधिकांश cppcheck चेक डिफ़ॉल्ट रूप से शामिल नहीं होते हैं। उनमें से जाँच की निम्नलिखित श्रेणियां हैं, जिनमें से प्रत्येक को स्वतंत्र रूप से चालू / बंद किया जा सकता है:

• त्रुटि - स्पष्ट त्रुटियां जो विश्लेषक महत्वपूर्ण मानता है और आमतौर पर कीड़े (डिफ़ॉल्ट रूप से सक्षम) को जन्म देता है;
• चेतावनी - चेतावनी, असुरक्षित कोड के बारे में संदेश यहां दिए गए हैं;
• शैली - शैलीगत त्रुटियां, संदेश गलत एन्कोडिंग के मामले में दिखाई देते हैं (अधिक अनुशंसाएं जैसे);
• प्रदर्शन - प्रदर्शन की समस्याएं, यहां कोडक को तेज कोड बनाने के लिए विकल्प प्रदान करता है (लेकिन यह हमेशा प्रदर्शन को बढ़ावा नहीं देता है);
• पोर्टेबिलिटी - संगतता त्रुटियां, आमतौर पर विभिन्न बिट आकारों के कंपाइलर या सिस्टम के विभिन्न व्यवहार से जुड़ी होती हैं;
• जानकारी - सूचनात्मक संदेश जो चेक के दौरान दिखाई देते हैं (कोड में त्रुटियों से संबंधित नहीं);
• अप्रयुक्त - अप्रयुक्त कार्यों (मृत कोड) की गणना करने का प्रयास, बहु-थ्रेडेड मोड में काम नहीं कर सकता;
• लापताइन्क्लूड - लापता #include के लिए जाँच करें (उदाहरण के लिए, यादृच्छिक का उपयोग करें, लेकिन stdlib.h कनेक्ट करने के लिए भूल गया)।

चेक को -enable पैरामीटर के साथ सक्षम किया जाता है , चेक श्रेणियों की सूची को अल्पविराम से अलग किया जाता है। उदाहरण के लिए:

 cppcheck -q -j4 --enable=warning,style,performance,portability ./source 

इस प्रकार, मैं आमतौर पर सबसे महत्वपूर्ण जांच शामिल करता हूं। एक सब कीवर्ड है जिसमें सूचीबद्ध सभी चेक शामिल हैं।

नोट। -J विकल्प और अनुपयोगी चेक मोड असंगत हैं, इसलिए -j अप्रयुक्त चेक को बंद कर देगा, भले ही यह स्पष्ट रूप से निर्दिष्ट किया गया हो।

एक टीम का उदाहरण जो सभी नियमों के अनुसार कोड को "ड्राइव" करता है:

 cppcheck -q --enable=all ./source 

और यह सब नहीं है। यदि आपका कार्यक्रम विश्लेषक के दृष्टिकोण से त्रुटि-मुक्त है, तो --inconclusive विकल्प के साथ cppcheck को चलाने का प्रयास करें। इस मोड में सभी संभावित जांच शामिल हैं, यहां तक ​​कि संभावना नहीं है कि डिफ़ॉल्ट रूप से स्किप्पेक चेक करता है।

इस प्रकार, सबसे विस्तृत सत्यापन मोड:

 cppcheck -q --enable=all --inconclusive ./source 

क्रॉस-प्लेटफ़ॉर्म के बारे में मत भूलना!

Cppcheck को मूल रूप से एक उपकरण के रूप में बनाया गया था जो विभिन्न ऑपरेटिंग सिस्टम और प्लेटफार्मों के साथ काम करता है। इसलिए, कार्यक्रम को किस प्लेटफॉर्म के लिए लिखा गया है और किस सत्यापन मोड का उपयोग करता है, इस पर नज़र रखना अनिवार्य है। प्लेटफ़ॉर्म को --platform विकल्प द्वारा स्विच किया जाता है ।

विभिन्न प्लेटफार्म:

• unix32 - सभी 32-बिट * निक्स (लिनक्स सहित);
• यूनिक्स 64 - सभी 64-बिट * निक्स;
• win32A - ASCII- एन्कोडेड 32-बिट विंडोज परिवार
• win32W - 32-बिट UNICODE- एन्कोडेड विंडोज का एक परिवार;
• win64 64-बिट विंडोज का एक परिवार है।

यदि आपको लिनक्स का उपयोग करके Win32 के लिए लिखे गए कोड की जांच करने की आवश्यकता है, तो आपको निश्चित रूप से प्लेटफ़ॉर्म निर्दिष्ट करना होगा:

 cppcheck --platform=win32A ./source 

आप यह निर्दिष्ट कर सकते हैं कि स्रोत कोड किस मानक पर लिखा गया है, जो कभी-कभी आपको चेक को परिष्कृत करने और नई त्रुटियों को पकड़ने की अनुमति देता है। निम्नलिखित विकल्पों के साथ --std विकल्प का प्रयोग करें:

• पॉज़िक्स - पोसिक्स मानक (लिनक्स सहित) के साथ संगत ओएस के लिए;
• c89 - सी भाषा, 89 वें वर्ष का मानक;
• सी 99 - सी भाषा, 99 वें वर्ष का मानक;
• सी 11 - सी भाषा, 11 वें वर्ष मानक (सी के लिए डिफ़ॉल्ट);
• सी ++ 03 - सी ++ भाषा, 3 साल का मानक;
• सी ++ 11 - सी ++ भाषा, 11 वीं वर्ष मानक (सी ++ के लिए डिफ़ॉल्ट)।

एक बार में दो मानकों का उपयोग किया जा सकता है:

 cppcheck --std=c99 --std=posix ./source 

उपयोगी कमांड लाइन तर्क

शायद यह पहले से ही हड़ताली है कि मैं हर जगह -q -j विकल्प का उपयोग करता हूं। उनकी आवश्यकता क्यों है? सबसे दिलचस्प पर विचार करें।

-j एक बहुत ही उपयोगी पैरामीटर है जो आपको मल्टी-थ्रेडेड मोड में स्कैन चलाने की अनुमति देता है। इसका उपयोग करना बहुत सरल है - प्रोसेसर की संख्या एक पैरामीटर के रूप में पारित की जाती है और सत्यापन अधिक मजेदार होगा।
-क् - मूक मोड। डिफ़ॉल्ट रूप से, cppcheck स्कैन की प्रगति (जो बहुत हो सकती है) के बारे में सूचनात्मक संदेश प्रदर्शित करता है। यह पैरामीटर पूरी तरह से सूचनात्मक संदेशों को बंद कर देता है, केवल त्रुटि संदेश ही रहते हैं।
-f या --force - ifdef निर्देशों के सभी विकल्पों की गणना सक्षम करें (डिफ़ॉल्ट रूप से, कैपचेक एक दर्जन विकल्पों की जांच करता है)। यह क्या है - फिर इसे अलग से माना जाएगा।
-v - डिबग मोड - cppcheck स्कैन की प्रगति के बारे में आंतरिक जानकारी प्रदान करता है।
--xml - XML ​​स्वरूप में सत्यापन का परिणाम प्रदर्शित करता है।
--template = gcc - gcc संकलक चेतावनी प्रारूप में त्रुटियां प्रदर्शित करें (ऐसे संकलक का समर्थन करने वाले IDE के साथ एकीकरण के लिए सुविधाजनक)।
--suppress - संकेत पहचानकर्ताओं के साथ त्रुटि दमन मोड (दोहराया विश्लेषण की आवश्यकता है)।
-h - शुद्ध अंग्रेजी में सभी मापदंडों पर मदद प्रदान करता है।

संदेश फ़िल्टरिंग और अपवाद

किसी भी स्वाभिमानी विश्लेषक की तरह, cppcheck आपको सत्यापन के दौरान त्रुटि प्रदर्शन को लचीले ढंग से कॉन्फ़िगर करने की अनुमति देता है। सबसे उपयोगी एक विशिष्ट फ़ाइल में एक विशिष्ट चेतावनी को अक्षम करने के लिए (और संभवतः एक विशिष्ट पंक्ति में) है। संदेशों को निष्क्रिय करना --suppress विकल्प के साथ कार्यान्वित किया जाता है , जहां आप अपवाद को निर्दिष्ट करना चाहते हैं, या - अपवाद की सूची वाली पाठ फ़ाइल के साथ -suppress-file । कमांड लाइन पर कुछ अपवादों को पारित करने के लिए, आप एक पंक्ति में कई - विकल्प लागू कर सकते हैं, लेकिन ऐसे उद्देश्यों के लिए अपवाद फ़ाइल रखना बेहतर है।

अपवाद स्वरूप:

 id[:file:[line]] 

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

उदाहरण के लिए, एक चेतावनी अक्सर पॉप अप होती है:

 The scope of the variable '%VAR' can be reduced. 

यह त्रुटि अधिकांश परियोजनाओं में निहित है और इसलिए कि यह रिफैक्टिंग करने की इच्छा को हतोत्साहित नहीं करती है, सबसे पहले मैं इसे बंद करने की सलाह देता हूं। यह निम्नलिखित तरीके से किया जा सकता है:

 cppcheck -q -j4 --enable=all --suppress=variableScope ./source 

जैसा कि आप इस उदाहरण से देख सकते हैं, cppcheck मानव-पठनीय त्रुटि पहचानकर्ताओं का उपयोग करता है, संख्याओं का नहीं, जिसे याद रखना बहुत आसान है।

--Errorlist पैरामीटर, जो XML प्रारूप में पूरी सूची प्रदर्शित करता है, सभी संभावित त्रुटियों की सूची खोजने में मदद करेगा। लेकिन मैं "आपत्तिजनक" संदेशों को निर्धारित करने की एक और विधि की सलाह दे सकता हूं। ऐसा करने के लिए, आपको --template पैरामीटर का उपयोग करके संदेश आउटपुट स्वरूप को बदलना होगा:

 cppcheck -q -j4 --enable=all --template='{id} {file}:{line} {message}' ./source 

मेरा टेम्प्लेट अब सबसे पहले संदेश के पहचानकर्ता को प्रदर्शित करता है, उसके बाद लाइन नंबर के साथ फाइल और अंत में, संदेश को ही। हस्तक्षेप करने वाले संदेश के पहचानकर्ता का पता लगाना आसान है।


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

 cppcheck -q --enable=all --template='{id}:{file}:{line}' ./source > suppress-list.txt 

अब परिणामी फाइल को cccheck इनपुट में जमा किया जा सकता है और आउटपुट में एक भी त्रुटि नहीं होगी। यह उपयोगी है जब विश्लेषण पूरा हो गया है और सभी विश्लेषक प्रतिक्रियाएं झूठी हैं।

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

हम इसमें शामिल हैं और परिभाषित करते हैं

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

अज्ञात एक चाल खेल सकता है। GLib पुस्तकालय में एक आम बात तर्कों की जांच करना है:

 void f(gchar *s1, gchar *s1) { g_return_if_fail(s1); gchar *a = g_strdup(s1); g_return_if_fail(s2); gchar *b = g_strdup(s2); } 

सब कुछ ठीक है सिवाय इसके कि g_return * मैक्रोज़ हैं जो त्रुटि के मामले में फ़ंक्शन को बाधित करते हैं। इस प्रकार, यदि फ़ंक्शन f का पहला तर्क सही निकला, और दूसरा नहीं, तो स्मृति रिसाव होता है। Cppcheck इस बात से अनजान है क्योंकि वह g_return_if_fail को डिफ़ॉल्ट रूप से एक "अच्छा कार्य" मानता है, न कि मैक्रो।

यदि आप आवश्यक शीर्ष लेख फ़ाइलों को शामिल करते हैं तो आप cppcheck के व्यवहार को बदल सकते हैं ताकि प्रीप्रोसेसर सभी आवश्यक कार्य करता है: यह मैक्रो कार्यान्वयन g_return_if_fail को ढूंढेगा , इसे खोलें, और cppcheck को बिना किसी सशर्त वापसी दिखाई देगी, जो एक मेमोरी लीक पैटर्न है।

प्रीप्रोसेसर काम करने के लिए जैसा कि इसे करना चाहिए, आपको उस पथ को निर्दिष्ट करने की आवश्यकता है जहां हेडर फ़ाइलों को देखना है। -I पैरामीटर इसके लिए जिम्मेदार है, जो समान नाम के gcc कंपाइलर पैरामीटर के समान है। GLib और Linux के लिए, यह एक पूर्वानुमानित मार्ग है:

 cppcheck -q -I/usr/include/glib-2.0/ ./source 

एक दिलचस्प विशेषता (जो विश्लेषण के समय को बढ़ाती है) ifdef विकल्पों की गणना है। यदि प्रोग्राम में एक ifdef है, तो cccheck दो प्रीप्रोसेसिंग विकल्प करेगा और स्रोत कोड के दोनों संस्करणों को स्कैन करेगा। जितनी अधिक ifdef शाखाएँ स्रोत कोड में होती हैं, उतने ही अधिक विकल्प आपके लिए आवश्यक हैं। आप इस व्यवहार को -D और -U विकल्पों के साथ नियंत्रित कर सकते हैं। -D A विकल्प का मतलब है कि मैक्रो A परिभाषित है। -U B विकल्प का अर्थ है कि मैक्रो B अपरिभाषित है।

डिफ़ॉल्ट रूप से, केवल एक दर्जन कॉन्फ़िगरेशन की जांच की जाती है। आप इस नंबर को --max-configs पैरामीटर के साथ बदल सकते हैं। केवल एक कॉन्फ़िगरेशन को सत्यापित करने के लिए, आप एक कॉन्फ़िगरेशन का सत्यापन निर्दिष्ट कर सकते हैं। --Force विकल्प सभी कॉन्फ़िगरेशन (बहुत धीरे-धीरे) की जांच करेगा।

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

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

हम स्वतंत्र रूप से कार्यों के कार्यान्वयन लिखते हैं

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

फ़ाइल को फ़ंक्शंस के कार्यान्वयन के साथ कनेक्ट करना --append पैरामीटर द्वारा कार्यान्वित किया जाता है। निर्दिष्ट फ़ाइल स्वचालित रूप से प्रत्येक प्रोजेक्ट फ़ाइल के अंत में डाली जाती है।

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

उदाहरण के लिए, प्रोग्राम GLib लाइब्रेरी का उपयोग करता है और आपको यह बताने की आवश्यकता है कि g_return_if_fail एक मैक्रो है।

आइए इस कोड का विश्लेषण करने की कोशिश करते हैं:

 void f(char *s1, char *s1) { g_return_if_fail(s1); char *a = g_strdup(s1); g_return_if_fail(s2); char *b = g_strdup(s2); free(a); free(b); } 

Cppcheck चलाएं:

 cppcheck -q test.c 

कोई बात नहीं।

निम्नलिखित सामग्रियों से एक gtk.h फ़ाइल बनाएँ:

 #define g_return_if_fail(expr) do{if(!(expr)){return;}}while(0) 

चूंकि यह एक मैक्रो है, आपको इसे शुरुआत में शामिल करने की आवश्यकता है:

 cppcheck -q test.c --include=gtk.h 

हम्म। फिर कुछ नहीं? यदि आप उदाहरण में कोड को करीब से देखते हैं, तो आप g_strdup फ़ंक्शन को देखेंगे, जिसके बारे में cppcheck अभी तक नहीं जानता है। आइए सरलतम कार्यान्वयन ( gtk.c फ़ाइल) लिखने का प्रयास करें:

 char * g_strdup(const char *s) { return strdup(s); } 

कृपया ध्यान दें कि यह एक फ़ंक्शन है, मैक्रो नहीं।
हम विश्लेषण करते हैं। फ़ंक्शन के कार्यान्वयन के साथ फ़ाइल को --append पैरामीटर के साथ डाला गया है;

 cppcheck -q test.c --include=gtk.h --append=gtk.c [test.c:4]: (error) Memory leak: a 

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

यह उदाहरण छत से नहीं लिया गया है: यह GLib कार्यक्रमों में सबसे आम त्रुटियों में से एक है जो मुझे लगातार मिलती है।

मैक्रो एंड इम्प्लीमेंटेशन ट्रिक्स

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

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

कस्टम मेमोरी आवंटन

मान लीजिए कि एक फ़ंक्शन my_alloc है जो अपने तर्कों के अंदर मेमोरी आवंटित करता है:

 my_alloc(char **a); 

निम्नलिखित उदाहरण को स्मृति रिसाव के रूप में मान्यता नहीं दी जाएगी:

 void f(){ char *a, *b; my_alloc(&a, &b); } 

अब कार्यान्वयन जोड़ें:

 void my_alloc(char **a, char **b) { *a = malloc(13); *b = malloc(42); } 

और चेक निम्नलिखित का उत्पादन करेगा:

 [test.c:4]: (error) Memory leak: a [test.c:4]: (error) Memory leak: b 

चेक से फ़ंक्शन को बाहर करें

यदि कोई ऐसा कार्य है जिसे हम जाँचना नहीं चाहते हैं, तो इसे छिपाना आसान है:

 #define unused_func(arg...) 

त्रुटि ध्वज के साथ स्मृति आबंटन

स्मृति को आवंटित करते समय कुछ कार्य, उनके तर्कों के माध्यम से एक त्रुटि की रिपोर्ट कर सकते हैं। उदाहरण के लिए, ऐसा कोड सही है:

 void f() { int is_ok; char *a = my_alloc(&is_ok); if(is_ok) free(a); } 

हालाँकि, यदि cppcheck my_alloc को मेमोरी आवंटन फ़ंक्शन के रूप में सूचीबद्ध किया गया है, तो चेक का परिणाम एक त्रुटि होगा। इससे बचने के लिए, आप निम्न चाल का उपयोग कर सकते हैं:

 char *my_alloc(int *ok) { char *a = malloc(42); if(a) *ok = 1; else *ok = 0; return a; } 

पुस्तकालय-विशिष्ट विश्लेषण

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

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

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

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

 gchar *s = g_strdup("test"); gint *a = g_malloc(sizeof(int) * 10); 

तथ्य यह है कि g_strdup और g_malloc के बाद मेमोरी को मुक्त करने की आवश्यकता होती है, एक व्यक्ति GLB के साथ पिछले अनुभव के बिना, सहज रूप से अनुमान लगाएगा। आप विश्लेषक के बारे में नहीं कह सकते: g_malloc फ़ंक्शन का कार्यान्वयन लाइब्रेरी के बाइनरी कोड के अंदर छिपा हुआ है - कौन जानता है कि यह वहां क्या करता है?

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

Cppcheck के बारे में सबसे अच्छी बात यह है कि इसमें ऐसा एक पुनःप्राप्त डेटाबेस है। इसका मतलब है कि समुदाय मानक पुस्तकालयों के बारे में सभी नई जानकारी जोड़कर cppcheck में सुधार कर सकता है जो cppcheck फिर विश्लेषण में उपयोग करेगा।

कैपचेक स्वचालित रूप से आवश्यक पुस्तकालयों को लोड नहीं करता है, इसे मैन्युअल रूप से किया जाना चाहिए। पुस्तकालयों को - सीमा विकल्प के साथ निर्दिष्ट किया जाता है , आप कई पुस्तकालयों को कॉमा से अलग करके निर्दिष्ट कर सकते हैं। नाम की एक फ़ाइल के लिए पहले दिखता cppcheck biblioteka.cfg वर्तमान निर्देशिका (ताकि अपनी परियोजना के लिए एक पुस्तकालय स्टोर करने के लिए सुविधाजनक) में, और फिर अपने डेटाबेस पुस्तकालयों में यह खोजने की कोशिश करता। यदि लाइब्रेरी कहीं नहीं मिली, तो cppcheck एक त्रुटि फेंक देगा। Gtk

लाइब्रेरी का उपयोग करके परियोजना विश्लेषण का एक उदाहरण :

 cppcheck -q --library=gtk ./source 

आप स्पष्ट रूप से संकेत कर सकते हैं कि लाइब्रेरी किस फ़ाइल में है (मुझे कहना चाहिए, स्रोत को देखे बिना, मैंने अनुमान नहीं लगाया होगा कि यह किया जा सकता है):

 cppcheck -q --library=my/path/mylib.xml ./source 

आज तक, cppcheck बहुत कम पुस्तकालयों का समर्थन करता है:

• gtk (वास्तव में, glib, gtk वहां समर्थित नहीं है)
• क्यूटी
• विंडोज़ (सभी प्रकार के स्कैनफ_एस ...)
• POSIX
• glibc (मानक पुस्तकालय हार्ड-कोडित होना बंद कर देता है और धीरे-धीरे डेटाबेस से अलग हो जाता है)

सूची स्पष्ट रूप से समृद्ध नहीं है। इसके अलावा, इस डेटाबेस की सामग्री से मैं एक चुभने वाला आंसू लेना चाहता हूँ, उदाहरण के लिए, यहाँ POSIX डेटाबेस है:

 <?xml version="1.0"?> <def> <function name="usleep"> <noreturn>false</noreturn> <arg nr="1"><not-bool/><valid>0-999999</valid></arg> </function> <function name="_exit"> <noreturn>true</noreturn> </function> </def> 

इस फ़ाइल से केवल एक चीज को चमकाया जा सकता है: cppcheck XML का उपयोग अपने आधार का विस्तार करने के लिए करता है।

वर्तमान में लाइब्रेरी डेटाबेस से "मछली को बाहर निकालने" में क्या सक्षम है:

• , / — ;
• , ( exit);
• , (, strlen );
• , ;
• - ( printf);

( )

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

प्रत्येक फ़ाइल एक हेडर से शुरू होती है:

 <?xml version="1.0"?> 

पूरा डेटाबेस डीफ़ टैग में लिपटा हुआ है । डिफ के अंदर तीन अलग-अलग टैग हो सकते हैं:

• मेमोरी - स्मृति के साथ काम करने वाले कार्यों के बारे में जानकारी;
• संसाधन - इसी तरह, लेकिन संसाधनों के लिए (खुला / बंद), एक विशिष्ट प्रतिनिधि खुला / बंद है ;
• फंक्शन सिर्फ एक फंक्शन है।

के रूप में स्मृति और संसाधन , आंतरिक संरचना को वे एक ही है:

• आवंटित - आवंटनकर्ता को टैग के अंदर रखा गया है, आप टैग विशेषता init = "true | false" जोड़ सकते हैं - यह इंगित करता है कि क्या आवंटनकर्ता मेमोरी को इनिशियलाइज़ करता है;
• dealloc - टैग स्मृति स्मृति आवंटन इकाई में सभी कार्यों की रिहाई समारोह के लिए इसी के भीतर स्थित (कई गठजोड़ कर सकते हैं alloc / dealloc एक इकाई में);
• use — , , (, ). , .

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

फ़ंक्शन ( फ़ंक्शन ) - इसमें सबसे बड़ी संख्या है विशेषताएं। फ़ंक्शन का नाम फ़ंक्शन टैग के नाम विशेषता के रूप में निर्दिष्ट किया गया है । टैग के अंदर आप उपयोग कर सकते हैं:

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

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

हम GLib पुस्तकालय का वर्णन करते हैं

GLib एक C भाषा पुस्तकालय है जो GTK + को रेखांकित करता है और C (और हाल ही में आत्मनिरीक्षण किया गया है) में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को लागू करता है। इस पर बहुत सारी परियोजनाएँ बनाई गई हैं: GIMP, GNOME, Xfce, यहां तक ​​कि क्रोमियम / फ़ायरफ़ॉक्स एक सीमा तक या किसी अन्य का उपयोग करते हैं।

GLib क्रॉस-प्लेटफ़ॉर्म है, इसलिए यहां तक ​​कि Malloc / free या printf जैसे फ़ंक्शंस को GLib के अंदर डुप्लिकेट किया जाता है ताकि ग्लिबेक समर्थित प्लेटफ़ॉर्म के विशिष्ट कार्यान्वयन या संस्करण पर निर्भर न हो। नतीजतन, GLib में मेमोरी के साथ काम करने वाले दर्जनों कार्य हैं, अपने स्वयं के त्रुटि हैंडलर, सामान्य तौर पर, सब कुछ जो cppcheck पर संदेह नहीं करता है।

Cppcheck में केवल हाल ही में GLib लाइब्रेरी सपोर्ट की अशिष्टता दिखाई दी। उदाहरण के लिए, cppcheck ऐसी स्पष्ट मेमोरी लीक को पकड़ सकता है:

 void f() { g_malloc(42); } 

 cppcheck -q test.c --library=gtk [test.c:3]: (error) Return value of allocation function g_malloc is not used. 

हालाँकि, GLib में सैकड़ों कार्य हैं, और इस तरह की एक जटिल जटिलता अब नहीं होगी:

 void f() { gchar *a = g_strdup(s); g_strdown(a); } 

ऐसा इसलिए है क्योंकि g_strdown फ़ंक्शन अज्ञात है। अचानक वह अपनी याददाश्त खुद मुक्त करती है?

GLib लाइब्रेरी को सशर्त रूप से इसके घटक भागों में विभाजित किया जा सकता है:

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

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

सौभाग्य से, यह सब काम (जीएलआईबी / जीटीके + परिवार के लिए) नहीं करना होगा, क्योंकि यह पहले ही पूरा हो चुका है और परिणाम मेरे भंडार में है ।

चूंकि मुझे एक्सएमएल से एलर्जी है, इसलिए मैंने उन कार्यों का वर्णन करने के लिए प्रारूप का एक सरलीकृत संस्करण बनाया, जो तब एक विशाल XML फ़ाइल में चिपके रहते हैं, जिसमें अजगर में लिखा एक छोटा पार्सर होता है। XML फ़ाइल प्राप्त करने के लिए, बस टाइप करें। दो सूत्रों: gtk.rules , जहां मैनुअल सूचियों कार्यों कि स्वचालित रूप से पार्स नहीं किया जा सकता है, और जीटीके-functions.rules - स्वचालित रूप से उत्पन्न फ़ाइल XML- आधारित इंटरफेस GLib / जीटीके +। पार्सर को लिखा जाता है ताकि कार्यों को दोहराया न जाए।

फिलहाल, लाइब्रेरी कमोबेश स्थिर है, आप इसे यहां से उठा सकते हैं और इसे cppcheck /ff निर्देशिका में डाल सकते हैंपुराने की जगह ले रहा है। उसके बाद, आप GLib / GTK + में लिखे गए किसी भी प्रोजेक्ट का विश्लेषण कर सकते हैं। झूठी सकारात्मकता का परीक्षण करने और समाप्त करने के बाद, मैं इस डेटाबेस के साथ पुल अनुरोध को cppcheck में धकेलने का प्रयास करूंगा, इसलिए इसे अगली रिलीज़ में देखने का मौका है।

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

थूनर स्रोत कोड विश्लेषण

पुस्तकालय का उपयोग विश्लेषण को कैसे प्रभावित करता है इसका एक छोटा उदाहरण। आज, थुनेर संस्करण 1.6.3 एक प्रयोगात्मक एक होगा, इसमें कोई गहन विश्लेषण नहीं होगा (यह प्रदर्शन के लिए आवश्यक नहीं होगा), बस मानक सेटिंग्स के साथ एक स्कैन।

सबसे पहले, एक "साफ" cppcheck विश्लेषण:

 cppcheck -q -j4 --max-configs=1 ./Thunar-1.6.3 [Thunar-1.6.3/thunar/thunar-chooser-dialog.c:450]: (error) Uninitialized variable: app_info 

बहुत कम कैच।

हम पुस्तकालय कनेक्ट करते हैं:

 cppcheck -q -j4 --max-configs=1 --library=gtk --include=gtk.h ./Thunar-1.6.3 

27 नए कीड़े - अब कुछ!

क्या ये वास्तव में कीड़े हैं या झूठी सकारात्मकता का एक गुच्छा है?

त्रुटि जाँच की स्थिति में स्मृति रिसाव स्मृति रिसाव का सबसे सामान्य प्रकार है:

  tmpdir = g_strdup ("/tmp/thunar-sendto-email.XXXXXX"); if (G_UNLIKELY (mkdtemp (tmpdir) == NULL)) { error = g_error_new_literal (G_FILE_ERROR, g_file_error_from_errno (errno), g_strerror (errno)); tse_error (error, _("Failed to create temporary directory")); g_error_free (error); return FALSE; } /* -   */ g_free(tmpdir); 

कंस्ट्रक्टर / डिस्ट्रक्टर मिसमैच। यह वास्तव में एक मेमोरी लीक है, क्योंकि सरणी की आंतरिक संरचना को मुक्त नहीं किया गया है। नीचे दिए गए कोड त्रुटियों के बिना ठीक काम करेंगे, लेकिन सरणी के तत्वों में प्रवाह करेंगे :

  gchar **attrs; ... attrs = g_file_info_list_attributes (info1, NULL); ... g_free (attrs); 

पॉइंटर जारी होने पर लौटा दिया जाता है:

  GtkTreePath *path = NULL; GtkTreeIter iter; ThunarFile *file = NULL; path = (*THUNAR_STANDARD_VIEW_GET_CLASS (standard_view)->get_path_at_pos) (standard_view, x, y); if (G_LIKELY (path != NULL)) { gtk_tree_model_get_iter (GTK_TREE_MODEL (standard_view->model), &iter, path); file = thunar_list_model_get_file (standard_view->model, &iter); if (!thunar_file_is_directory (file) && !thunar_file_is_executable (file)) { g_object_unref (G_OBJECT (file)); /*     ! */ gtk_tree_path_free (path); path = NULL; } } return file; 

यह एक विवादास्पद चेतावनी है, क्योंकि g_object_unref लिंक को गिनता है और क्या ऑब्जेक्ट हटाया जाएगा अज्ञात है, लेकिन यह देखने लायक है।

झूठी सकारात्मकता। कुछ थे - कुछ gtk फ़ंक्शन आपको एक ऐसी वस्तु को अलग करने की अनुमति देते हैं जो कि माता-पिता के साथ स्वचालित रूप से नष्ट हो जाएगी, अगर बाहर नहीं किया गया - cppcheck शपथ लेगा।


लेकिन इन झूठी सकारात्मकता का आकर्षण यह है कि उन्हें XML फ़ाइल को लाइब्रेरी के साथ पैच करके ठीक करना आसान है। इस प्रकार, त्रुटियों की संख्या को कम करना 14. संभव हो गया था। समय के साथ, जीएलआईबी में आत्मनिरीक्षण में सुधार किया जाएगा और पुस्तकालय के बारे में स्वचालित रूप से जानकारी एकत्र करना संभव होगा।

Cppcheck के लिए नियम लिखना

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

हुड के नीचे क्या है?

शुरू करने के लिए, कैसे cppcheck काम करता है के बारे में कुछ शब्द। विश्लेषण से पहले, cppcheck संकलक के समान प्रीप्रोसेसर चलाता है, जिसके बाद स्रोत कोड का सरलीकरण चरण अनुसरण करता है। वह है: सभी अनावश्यक इंडेंट और रिक्त स्थान हटा दिए जाते हैं, भाषा के प्रत्येक लेक्सिकल निर्माण को ठीक एक स्थान से अलग किया जाता है। सभी स्थिरांक जिन्हें प्रीप्रोसेसिंग के दौरान सरल किया जा सकता है, की गणना की जाती है। ब्लॉक {} को हर जगह रखा जाता है, भले ही वे छोड़े गए हों। यदि ब्लॉक के भीतर / / के लिए एक चर की घोषणा या असाइनमेंट है, तो इसे इस ब्लॉक के बाहर प्रदान किया जाएगा।

चूंकि सभी की एक अलग कोडिंग शैली होती है, इसलिए कोडपेक एक "सामान्य रूप" में कोड बनाने का प्रयास करता है। उदाहरण के लिए, एक प्रोग्रामर इस तरह एक लूप लिखता है:

 for(int i = 0; i < 10; i++) if(i % 2) printf("%d\n", i); 

और दूसरा इस तरह है:

 int i; for(i = 0; i < 10; i++) { if(i % 2) printf("%d\n", i); } 

Cppcheck यह सब फॉर्म में लाएगा:

 int i ; for ( i = 0 ; i < 10 ; i ++ ) { if ( i % 2 ) { printf ( "%d\n" , i ) ; } } 

बहुत पठनीय नहीं है, लेकिन विश्लेषण करने में आसान है। सभी शाब्दिक निर्माण बड़े करीने से रिक्त स्थान से अलग होते हैं और इनमें कुछ भी नहीं होता है।

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

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

यह समझने के लिए नहीं कि कैसे cppcheck कुछ डिज़ाइनों का अनुकूलन करता है, आप डिबग मोड का उपयोग कर सकते हैं जिसमें cppcheck कोड का सरलीकृत संस्करण प्रदर्शित करता है:

 cppcheck --debug ./file.cpp 

नियमित अभिव्यक्ति नियम

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

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

 make HAVE_RULES=yes 

Cppcheck में अब दो नए विकल्प होंगे: - nowlele - आप एक रेगुलर एक्सप्रेशन को सीधे कमांड लाइन और --rule-file - एक XML डेटाबेस पर अपने सत्यापन नियमों के साथ निर्दिष्ट कर सकते हैं ।

निम्नानुसार नए अवसर के साथ परिचित हो। टेस्ट केस:

 void f() { if(a) free(a); } 

अगला चेक आइए एक नियमित अभिव्यक्ति करें जो अपने लिए सब कुछ कुचल देती है:

 cppcheck -q --rule=".*" test.c [test.c:1]: (style) found ' void f ( ) { if ( a ) { free ( a ) ; } }' 

बहुत बढ़िया!अब यह स्पष्ट है कि किस तरह का "सरलीकृत" दृश्य है।

अब हम एक नियम लिखेंगे जो हमें मुक्त करने से पहले अनावश्यक परिवर्तनशील जाँच के लिए अनुमति देता है:

 cppcheck -q --rule='if \( (\w+) \) { free \( \1' test.c [test.c:2]: (style) found 'if ( a ) { free ( a' 

पैटर्न काम करता है। यह डेटाबेस पर लिखने के लिए रहता है। नियम बनाएँ। Xml फ़ाइल , नियमित अभिव्यक्ति को अंतिम रूप देते हुए:

 <?xml version="1.0"?> <rule> <pattern>if \( (\b\w+\b) \) { (?:g_)?free \( \b\1\b \) ; }</pattern> <message> <severity>style</severity> <summary>Redundant condition. It is valid to free a NULL pointer.</summary> </message> </rule> 

अब आप इस फ़ाइल को नियम आधार के रूप में उपयोग कर कुछ स्रोत की जाँच कर सकते हैं:

 cppcheck -q --rule-file=rules.xml test.c [test.c:2]: (style) Redundant condition. It is valid to free a NULL pointer. 

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

 <tokenlist>raw</tokenlist> 

टोकन टैग के अंदर, आप उपयोग कर सकते हैं:

• कच्चे - न्यूनतम सरलीकरण के साथ कोड
• सामान्य - डिफ़ॉल्ट मोड
• सरल - सबसे सरल कोड
• परिभाषित करना - प्रीप्रोसेसर निर्देशों की जांच करने के लिए, cppcheck मैक्रो को स्रोत से बाहर नहीं करता है

यदि आप सारांश टैग को हटाते हैं - आप देख सकते हैं कि कौन सी रेखा नियमित अभिव्यक्ति के अंतर्गत आती है - यह डिबगिंग मोड है।

नियमों के कुछ उदाहरण:





जैसा कि आप जानते हैं, मुझे एक्सएमएल से एलर्जी है, इसलिए मैंने थोड़ा सरलीकृत आधार प्रारूप और पायथन कंपाइलर के साथ एक रिपॉजिटरी बनाई । मैंने जो XML डेटाबेस संकलित किया है, उसमें C प्रोग्रामिंग (C ++ नहीं!) में एक अच्छी टोन के लिए मुख्य CERT सिफारिशें शामिल हैं और धीरे-धीरे अपडेट की जाती हैं। जैसा कि वे कहते हैं, प्रतियोगिताओं का स्वागत है।

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

यदि आप अधिक जानना चाहते हैं, तो cppcheck के लिए नियम बनाने के विषय पर एक अच्छा दस्तावेज है: एक , दो , तीन (तीसरा भाग C ++ में नियमों के विकास के लिए समर्पित है)। आप डेवलपर्स पैच, झूठी सकारात्मक, बग्स के बारे में संदेश भेजकर और पीआर करने के लिए स्वतंत्र महसूस कर सकते हैं (कोई नहीं, लेकिन पुल अनुरोध :)।