🚁 🧘🏿 🎇 Cppcheck के साथ सोर्स कोड का विश्लेषण करना 💕 🈚️ 💫

C ++ कोड के स्थैतिक विश्लेषण पर कई हालिया लेखों के प्रकाश में, उपयोगकर्ताओं को बार-बार cppcheck विश्लेषक में दिलचस्पी रही है। यह एक अपेक्षाकृत युवा ओपन-सोर्स स्थैतिक विश्लेषण परियोजना है, जो मुख्य रूप से झूठी सकारात्मक के न्यूनतम मात्रा के साथ कोड में वास्तविक त्रुटियों को खोजने पर केंद्रित है।

हाल ही में, cppcheck ने Xorg परियोजना में एक भेद्यता खोजने में मदद की , जो लगभग 23 वर्षों से वहां मौजूद थी! यह पहले से ही दुनिया भर के हजारों प्रोग्रामरों की मदद कर चुका है, आधिकारिक वेबसाइट पर आप कार्यक्रमों में cppcheck का उपयोग करके पाई गई कमजोरियों के बारे में जानकारी पा सकते हैं, और यह सूची लगातार बढ़ रही है। इसलिए, यदि आप जानना चाहते हैं कि आपको हमेशा और हर जगह cppcheck का उपयोग करने की आवश्यकता क्यों है - मैं बिल्ली के लिए पूछता हूं।

Cppcat और cppcheck

मैं इन उपयोगिताओं की तुलना करके शुरू करूँगा, क्योंकि इस अनुरोध को टिप्पणियों में बार-बार आवाज दी गई है। CppCat डेवलपर्स पहले ही ऐसी तुलना कर चुके हैं (PVS-Studio के साथ), लेकिन तब से बहुत सारा पानी बह चुका है, और PVS- स्टूडियो (जहाँ तक मैं वाक्यांश की गूढ़ता को समझता हूँ, तुलना बहुत ही उद्देश्यपूर्ण नहीं है, कृपया हमें PVS की कीमत पाने के लिए लिखें। -स्टडियो। कृपया दिलचस्प लाइसेंस प्रकार निर्दिष्ट करें। ") एकल प्रोग्रामर के लिए इरादा नहीं है। Cppcat, cppcheck की तरह, सभी के ~~लिए उपलब्ध है~~ (कुछ संस्करणों के लिए VisualStudio और एक साल के लिए लाइसेंस के लिए आरक्षण के साथ)।

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

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

किस वजह से, खोज-स्थापित-विज़ुअल-स्टूडियो -2013-पुनर्स्थापना-IE-11-रिबूट-अपडेट खोज से परीक्षण जटिल हो गया, जो अपडेट के साथ बोझ नहीं बने वर्चुअल मशीन पर लगभग आधा दिन लगा।

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

ट्रेनिंग

चूंकि cppcheck एक ओपन सोर्स प्रोजेक्ट है, कोई भी गीता से नवीनतम संस्करण को डाउनलोड करने और इसे स्वयं संकलित करने के लिए परेशान नहीं करता है। Cppcheck डेवलपर्स के लिए अभिप्रेत है, इसलिए स्रोत कोड से किसी प्रोग्राम को संकलित करने से कोई समस्या नहीं होनी चाहिए:

unzip cppcheck-master.zip cd cppcheck-master make

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

टेस्ट कॉन्फ़िगरेशन: RHEL 6.1, i5-2400 @ 3.10GHz प्रोसेसर (विश्लेषक रनटाइम का मूल्यांकन करने के लिए)।

कार्रवाई के लिए सुविधा कमांड लाइन पर बनाई जाएगी - यदि वांछित है, तो उन्हें दोहराया जा सकता है (लिनक्स :) पर। बेशक, लोकप्रिय आईडीई के लिए cppcheck में कई प्लगइन्स हैं, लेकिन आज ऐसा नहीं है।

नोटपैड ++ विश्लेषण

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

एक उचित प्रश्न उठ सकता है - लिनक्स ऑपरेटिंग सिस्टम में नोटपैड ++ का विश्लेषण कैसे करें यदि नोटपैड ++ विशेष रूप से डब्ल्यूएएनपीआई का उपयोग करता है? इसका उत्तर सरल है - मेरी स्मृति में cppcheck एकमात्र ऐसा विश्लेषक है जो बिल्ड वातावरण या ऑपरेटिंग सिस्टम से जुड़ा नहीं है । यह अपने स्वयं के लेक्सिकल विश्लेषक का उपयोग करता है, सभी हेडर फ़ाइलों की उपस्थिति की आवश्यकता नहीं होती है, कक्षाओं की पेचीदगियों के प्रति वफादार है, आदि। यह अद्भुत संपत्ति आपको कहीं भी cppcheck का उपयोग करने की अनुमति देती है और कुछ के लिए जो CppCat के बारे में नहीं कहा जा सकता है (ऊपर स्थापना खोज देखें) ।

Cappcheck विश्लेषण अपमान के लिए सरल है:

 ./cppcheck-master/cppcheck -q -j4 npp.6.5.3.src/

जबकि सबसे सरल विश्लेषण बॉक्स से बाहर है। कमांड दो मापदंडों -q ("साइलेंट" मोड को परिभाषित करता है - स्क्रीन पर प्रगति प्रदर्शित नहीं करता है) और -j4 - प्रोसेसर कोर की संख्या से 4 थ्रेड्स में बहु-थ्रेडेड विश्लेषण।

पिछले आदेश का परिणाम:

 [npp.6.5.3.src/PowerEditor/src/tools/ChangeIcon/ChangeIcon.cpp:214]: (error) Mismatching allocation and deallocation: resData [npp.6.5.3.src/PowerEditor/src/tools/ChangeIcon/ChangeIcon.cpp:216]: (error) Mismatching allocation and deallocation: resData [npp.6.5.3.src/scintilla/lexers/LexBash.cxx] -> [npp.6.5.3.src/scintilla/lexers/LexBash.cxx:194]: (error) Internal error. Token::Match called with varid 0. Please report this to Cppcheck developers

ऑपरेटिंग समय - 5 मिनट। त्रुटि "(त्रुटि) आंतरिक त्रुटि। टोकन :: मिलान जिसे varid 0. के साथ कहा जाता है। कृपया इसे Cppcheck डेवलपर्स को रिपोर्ट करें" तुरंत आंख को पकड़ लेता है। इसका मतलब यह है कि विश्लेषण किए गए कार्यक्रम में एक बग के बजाय, विश्लेषक में एक बग था :) हम इस तथ्य पर छूट देंगे कि परियोजना विन के लिए अनुकूलित है, और cppcheck को संदेह नहीं है कि DWORD, LPTR, आदि का क्या मतलब है। शायद यह खुद को विन में अलग तरीके से दिखाएगा। ।

वास्तव में, केवल एक गलती थी (2 लाइनों के अंतर के साथ)। बुरा नहीं है, शायद नोटपैड ++ का लेखक स्वयं cppcheck का उपयोग करता है। कोड का वह टुकड़ा जिसने संदिग्ध बना दिया:

  BYTE* resData = new BYTE[cbRes]; LPBYTE writePtr = resData; ... if(!UpdateResource(hUpdate, RT_GROUP_ICON, lpResName, resLangId, resData, cbRes)) { _tprintf(_T("Unable to update icon group\n")); delete resData; return false; } IFDEBUG( _tprintf(_T("Updated group %d (lang %d)\n"), lpResName, resLangId); ) delete resData; }

यह एक झूठी सकारात्मक की तरह दिखता है, हालांकि स्रोत, स्पष्ट रूप से, चौंकाने वाला है। UPD: यह अभी भी एक अपरिभाषित व्यवहार है, सरणी को हटाना [] ऑपरेटर का उपयोग करके मुक्त किया जाना चाहिए।

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

 ./cppcheck-master/cppcheck -q -j4 --enable=performance,portability,warning,style npp.6.5.3.src/ 2> npp.out

--Enable पैरामीटर का उपयोग किया जाता है, जिसमें चेक की श्रेणियां शामिल हैं:

- प्रदर्शन - प्रदर्शन की समस्याएं;
- पोर्टेबिलिटी - संगतता मुद्दों;
- चेतावनी - चेतावनी - संदिग्ध कार्यक्रम स्थान;
- शैली - प्रोग्रामिंग शैली त्रुटियां।

इस मोड में, शेर की शैलीगत / तार्किक त्रुटियों और संभावित बग (यानी, त्रुटियां, जिसमें cppcheck "सुनिश्चित नहीं है") का हिस्सा पकड़ा जाता है। स्कैनिंग समय - 5 मिनट। मैंने तुरंत आँकड़ों को इकट्ठा करने के लिए एक फ़ाइल को परिणाम भेजा।

कुल संदेश:

 wc -l < npp.out 379

त्रुटियों के प्रकार पर छोटे आँकड़े:

 tr '()' '*' < npp.out | cut -d* -f2 | sort | uniq -c 3 error 39 performance 14 portability 211 style 112 warning

संदेश सांख्यिकी

 sort -t] -k2 npp.out | grep -v '(error)' | cut -d\) -f2- | sed "s/'[^']*'/%{VAR}/g" | sort | uniq -c | sort -n 1 Function parameter %{VAR} should be passed by reference. 1 memset() called to fill 0 bytes of %{VAR}. 1 scanf without field width limits can crash with huge input data. 1 The class %{VAR} does not have a constructor. 1 Unused variable: ent 1 Unused variable: loc 2 Array index %{VAR} is used before limits check. 2 Checking if unsigned variable %{VAR} is less than zero. 2 Found duplicate branches for %{VAR} and %{VAR}. 2 The class %{VAR} defines member variable with name %{VAR} also defined in its parent class %{VAR}. 2 Unsigned variable %{VAR} can't be negative so it is unnecessary to test it. 2 %{VAR} should return %{VAR}. 3 scanf without field width limits can crash with huge input data on some versions of libc. 4 Same expression on both sides of %{VAR}. 4 %{VAR} does not have a copy constructor which is recommended since the class contains a pointer to allocated memory. 5 Assignment of function parameter has no effect outside the function. 5 Ineffective call of function %{VAR}. Did you intend to call %{VAR} instead? 7 Consecutive return, break, continue, goto or throw statements are unnecessary. 11 Exception should be caught by reference. 11 The extra qualification %{VAR} is unnecessary and is considered an error by many compilers. 12 Variable %{VAR} is reassigned a value before the old one has been used. 22 Variable %{VAR} is assigned a value that is never used. 26 Variable %{VAR} is assigned in constructor body. Consider performing initialization in initialization list. 42 C-style pointer casting 98 Member variable %{VAR} is not initialized in the constructor. 108 The scope of the variable %{VAR} can be reduced.

कुल 28 अनोखे संदेश।

संदेश "चर% {VAR} का दायरा कम किया जा सकता है", "C- शैली सूचक कास्टिंग", "चर% {VAR} को निर्माता निकाय में असाइन किया गया है।" पर विचार नहीं किया जा सकता है - ये ऐसी शैलीगत सिफारिशें हैं जो कई परियोजनाओं के लिए बहुत महत्वपूर्ण हैं। पुराने पेशेवरों पर लिखा है।

कंस्ट्रक्टर में वैरिएबल के एक समुद्र को आरंभीकृत नहीं किया जाता है। ( चेतावनी ) सदस्य वैरिएबल% {VAR} को कंस्ट्रक्टर में आरंभीकृत नहीं किया जाता है। यह त्रुटि cppcheck चेतावनी मानती है। शायद इस तरह के कोड का व्यवहार संकलक पर निर्भर करता है, क्योंकि एनपीपी कुछ चमत्कार से काम करता है।

उदाहरण

 //[npp.6.5.3.src/PowerEditor/src/WinControls/AnsiCharPanel/ansiCharPanel.h:46]: (warning) Member variable 'AnsiCharPanel::_ppEditView' is not initialized in the constructor. class AnsiCharPanel : public DockingDlgInterface { public: AnsiCharPanel(): DockingDlgInterface(IDD_ANSIASCII_PANEL) {}; void init(HINSTANCE hInst, HWND hPere, ScintillaEditView **ppEditView) { DockingDlgInterface::init(hInst, hPere); _ppEditView = ppEditView; }; virtual void display(bool toShow = true) const { DockingDlgInterface::display(toShow); }; void setParent(HWND parent2set){ _hParent = parent2set; }; void switchEncoding(); void insertChar(unsigned char char2insert) const; protected: virtual BOOL CALLBACK AnsiCharPanel::run_dlgProc(UINT message, WPARAM wParam, LPARAM lParam); private: ScintillaEditView **_ppEditView; ListView _listView; };

एक वैरिएबल का प्रारंभ कंस्ट्रक्टर में नहीं है, लेकिन इनिट फ़ंक्शन में है, इसलिए मेरी राय में केस पर वोरिंग।

( शैली ) '||' के दोनों ओर समान अभिव्यक्ति। एक ही स्थिति का सत्यापन। उसी त्रुटि को CppCat द्वारा निर्मित किया गया था, हालाँकि, या तो npp संस्करण उस लेख में पुराना है, या त्रुटि पहले से ही तय हो गई है, लेकिन अब एक ही कोड इस तरह दिखता है:

 while (closeFound.success && (styleAt == SCE_H_DOUBLESTRING || styleAt == SCE_H_SINGLESTRING) && searchStartPoint <= caret);

और यह नया कैचचेक कैच है:

 if (!(!commentLineSybol || !commentLineSybol[0] || commentLineSybol == NULL))

( प्रदर्शन ) वैरिएबल 'लाइनइंडेंट' का उपयोग करने से पहले पुराने मान को पुन: असाइन किया जाता है। संक्षेप में, डबल असाइनमेंट। यह आमतौर पर कॉपी-पेस्ट का एक परिणाम है, लेकिन कैप्पेक एक प्रदर्शन त्रुटि के रूप में ऐसी त्रुटि की विशेषता है। यह कोड जांचने लायक है, क्योंकि यह ज्ञात नहीं है कि कार्यक्रम के लेखक का क्या मतलब है। ऐसे कई दोहरे कार्य हैं, साथ ही कोड द्वारा चर के अप्रयुक्त मान:

  int lineIndent = lineStart; ... lineIndent = _pEditView->execute(SCI_GETLINEINDENTPOSITION, i); _pEditView->getGenericText(linebuf, linebufferSize, lineIndent, lineEnd);

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

( पोर्टेबिलिटी ) अतिरिक्त योग्यता 'FunctionListPanel ::' अनावश्यक है और कई संकलक द्वारा एक त्रुटि मानी जाती है। एक उपयोगी चेतावनी जो शारीरिक रूप से उपलब्ध नहीं है और CppCat में नियोजित नहीं है: विभिन्न प्लेटफार्मों (पोर्टेबिलिटी) के बीच पोर्टेबिलिटी त्रुटियां। सभी कंपाइलरों में यह कोड काम नहीं करेगा:

 virtual BOOL CALLBACK FunctionListPanel::run_dlgProc(UINT message, WPARAM wParam, LPARAM lParam);

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

( शैली ) अपवाद को संदर्भ द्वारा पकड़ा जाना चाहिए। एक दिलचस्प चेतावनी अपवाद को संदर्भ से पकड़ना है , और मूल्य से नहीं:

  catch(std::exception e) { ::MessageBoxA(NULL, e.what(), "Exception", MB_OK); return -1; }

( शैली ) लगातार रिटर्न, ब्रेक, जारी, गोटो या थ्रो स्टेटमेंट अनावश्यक हैं। डेड कोड: वापसी के बाद ब्रेक:

  switch(lpnm->wID) { case REBAR_BAR_TOOLBAR: { ... return TRUE; break; } }

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

 void SetValue( const TCHAR* _value ) { value = _value; }

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

 if ( sscanf( value.c_str(), "%d", ival ) == 1 )

संख्याओं को परिवर्तित करने के लिए, सुरक्षित स्ट्रैटोल का उपयोग करना बेहतर है।

एक अन्य प्रतिनिधि:

 sscanf( wordBuffer, "%[^.<>|&=\\/]", sKeywordBuffer );

कोई बफर अतिप्रवाह नहीं है क्योंकि wordBuffer और sKeywordBuffer एक ही आकार के हैं।

( शैली ) 'TiXmlStringA :: ऑपरेटर =' को 'TiXmlStringA &' वापस करना चाहिए। = ऑपरेटर शून्य देता है:

 void operator = (const TiXmlStringA & copy);

इस ऑपरेटर के साथ, आप मानक C ++ श्रृंखला का उपयोग नहीं कर सकते:

 a = b = c;

( चेतावनी ) वर्ग 'ControlsTab' सदस्य चर को '_isVertical' नाम से परिभाषित करता है जिसे इसके मूल वर्ग 'TabBar' में भी परिभाषित किया गया है। एक वर्ग में एक चर की दोहरी परिभाषा की त्रुटि:

 class ControlsTab : public TabBar { public : ... private : ... bool _isVertical; };

जो पहले से ही मूल वर्ग में परिभाषित है:

 class TabBar : public Window { ... protected: ... bool _isVertical; };

पेशेवरों में विशेषज्ञ नहीं होने के कारण, मैं तुरंत जवाब नहीं दे सकता कि क्या ऐसा करना संभव है (संरक्षित / निजी)।

( शैली ) 'यदि' और 'अन्य' के लिए डुप्लिकेट शाखाएं मिलीं। CppCat में समान त्रुटियां पाई गईं। अतिरिक्त स्थिति:

  if(eol_mode == SC_EOL_CRLF) extraEOLLength = 2; else if(eol_mode == SC_EOL_LF) extraEOLLength = 1; else // SC_EOL_CR extraEOLLength = 1;

( शैली ) यदि अहस्ताक्षरित चर 'lenFile' शून्य से कम है, तो जाँच करना। CppCat द्वारा एक समान संदेश जारी किया गया था, सिवाय इसके कि cccheck, windows.h फ़ाइल का पता लगाए बिना, WPARAM जैसे प्रकारों की परिकल्पना नहीं करता था। अभी भी विशेष रूप से विंडोज पर गैर-अभिविन्यास का नुकसान है।

  size_t lenFile = 0; ... if (lenFile <= 0) break;

मुझे लगता है कि अगर मेरे पास विंडोज हेडर फाइलें थीं, तो आप उन्हें -I विकल्प के माध्यम से पथ निर्दिष्ट कर सकते हैं, तो बहुत अधिक त्रुटियां होंगी।

( शैली ) एरे इंडेक्स 'जे' का उपयोग सीमा जाँच से पहले किया जाता है। इस तथ्य के बावजूद कि चेतावनी कम प्राथमिकता है, जो त्रुटि मिली है वह सरणी की सीमाओं से परे जाने का खतरा है:

  int j; int ReturnValue; j=startcol; if(direction == 1){j++;} if(direction != 1){j--;} while((BGHS[SI].columnwidths[j] == 0)&&(j<=BGHS[SI].cols)&&(j>0))

यह देखते हुए कि स्टार्टर पैरामीटर बाहरी है, आप सरणी के सीमा से बाहर उड़ सकते हैं, -1 इंडेक्स का उल्लेख नहीं करने के लिए।

( स्टाइल ) अनसाइनड वेरिएबल 'i' निगेटिव नहीं हो सकता इसलिए इसे टेस्ट करना अनावश्यक है। लूप में स्थिति हमेशा सकारात्मक होती है => अनंत लूप:

 for(unsigned int i = position_of_click; i >= 0; --i)

Gcc कंपाइलर और -Wall -Wextra झंडे के साथ प्रोजेक्ट बनाते समय इस त्रुटि से बचा जा सकता था। मुझे लगता है कि यह त्रुटि अक्सर तब दिखाई देती है जब किसी अन्य संकलक त्रुटि के लिए एक परियोजना को रिफैक्ट करते हैं - बेमेल प्रकार। यह int था - यह अहस्ताक्षरित हो गया, यहाँ परिणाम है।

छोटी-मोटी खामियां

( शैली ) अप्रयुक्त चर: एंट। यह चेतावनी संकलक द्वारा भी जारी की जा सकती है, कुछ भी दिलचस्प नहीं है।

( चेतावनी )% d प्रारूप स्ट्रिंग में (संख्या 2) के लिए 'int' की आवश्यकता होती है, लेकिन तर्क प्रकार 'DWORD {उर्फ अहस्ताक्षरित लंबा}' है - एक बहुत ही लोकप्रिय त्रुटि, printf में प्रोग्रामर एक प्रकार लिखते हैं जो चर के प्रकार से मेल नहीं खाते हैं। यह भी अधिकांश संकलक द्वारा निकाल दिया जाता है।

निर्माता के बिना वर्ग:

  class CachedValue { generic_string fullname; int index; };

( प्रदर्शन ) फ़ंक्शन पैरामीटर 'रेंज' को संदर्भ द्वारा पारित किया जाना चाहिए। cppcheck तर्क की नकल से बचने के लिए संदर्भ द्वारा एक पैरामीटर पास करने की सिफारिश करता है:

 XYScrollPosition XYScrollToMakeVisible(const SelectionRange range, const XYScrollOptions options);

( चेतावनी ) फ़ंक्शन के अप्रभावी कॉल 'खाली ()'। क्या आपने इसके बजाय 'स्पष्ट ()' कहने का इरादा किया था? खाली विधि केवल स्थिति के अंदर समझ में आती है और रेखा को साफ नहीं करती है। यह एक गलत सकारात्मक है, cppcheck को संदेह नहीं था कि लेखक अपना स्ट्रिंग वर्ग बना देगा :) विधि नामकरण तर्क की जाँच की जानी चाहिए।

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

निष्कर्ष

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

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

विश्लेषण परिणाम XML को निर्यात किया जा सकता है और एक ब्राउज़र में देखा जा सकता है।

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

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

PS कृपया एक बकवास क्षमा करें। Cppcheck की सेटिंग्स में विशेष रूप से विंडोज के लिए कोड का विश्लेषण करने की क्षमता है, क्योंकि इसमें बहुत सारी दिलचस्प त्रुटियां याद की गईं। झंडे के साथ एनपीपी का विश्लेषण करना आवश्यक था --platform = win32A।

Cppcheck के साथ सोर्स कोड का विश्लेषण करना

Cppcat और cppcheck

ट्रेनिंग

नोटपैड ++ विश्लेषण

छोटी-मोटी खामियां

निष्कर्ष

More articles: