CMake: वह मामला जब परियोजना की गुणवत्ता अक्षम्य है

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

परिचय

सीएमके सोर्स कोड से सॉफ़्टवेयर बिल्डिंग को स्वचालित करने के लिए एक क्रॉस-प्लेटफ़ॉर्म सिस्टम है। CMake का सीधा मतलब भवन के लिए नहीं है, यह केवल CMakeLists.txt फाइलों से एक बिल्ड को नियंत्रित करने के लिए फाइलें उत्पन्न करता है। कार्यक्रम की पहली रिलीज 2000 में हुई थी। तुलना के लिए, पीवीएस-स्टूडियो विश्लेषक केवल 2008 में दिखाई दिया था। उस समय, इसका उद्देश्य 32-बिट सिस्टम को 64-बिट में पोर्ट करने के परिणामस्वरूप बग की खोज करना था। 2010 में, सामान्य प्रयोजन निदान का पहला सेट दिखाई दिया (V501- V545 )। वैसे, सीएमके कोड को इस पहले सेट से कुछ चेतावनी है।

अक्षम्य त्रुटियां

V1040 पूर्व-परिभाषित मैक्रो नाम की वर्तनी में संभावित टाइपो। '__MINGW32_' मैक्रो '__MINGW32__' के समान है। विनापी.ह 4112

/* from winternl.h */ #if !defined(__UNICODE_STRING_DEFINED) && defined(__MINGW32_) #define __UNICODE_STRING_DEFINED #endif 

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

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

V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 558

 bool IsVisualStudioMacrosFileRegistered(const std::string& macrosFile, const std::string& regKeyBase, std::string& nextAvailableSubKeyName) { .... if (ERROR_SUCCESS == result) { wchar_t subkeyname[256]; // <= DWORD cch_subkeyname = sizeof(subkeyname) * sizeof(subkeyname[0]); // <= wchar_t keyclass[256]; DWORD cch_keyclass = sizeof(keyclass) * sizeof(keyclass[0]); FILETIME lastWriteTime; lastWriteTime.dwHighDateTime = 0; lastWriteTime.dwLowDateTime = 0; while (ERROR_SUCCESS == RegEnumKeyExW(hkey, index, subkeyname, &cch_subkeyname, 0, keyclass, &cch_keyclass, &lastWriteTime)) { .... } .... } 

सांख्यिकीय रूप से घोषित सरणी के लिए, आकार का ऑपरेटर तत्वों की संख्या और उनके आकार को ध्यान में रखते हुए, बाइट्स में आकार की गणना करेगा। Cch_subkeyname वैरिएबल के मान का मूल्यांकन करते समय, एक डेवलपर ने इसे ध्यान में नहीं रखा और उसे आशय से 4 गुना अधिक मूल्य मिला। आइए बताते हैं कि "चार बार" कहां से आता है।

सरणी और इसके गलत आकार को RegEnumKeyExW फ़ंक्शन में पास किया गया है:

 LSTATUS RegEnumKeyExW( HKEY hKey, DWORD dwIndex, LPWSTR lpName, // <= subkeyname LPDWORD lpcchName, // <= cch_subkeyname LPDWORD lpReserved, LPWSTR lpClass, LPDWORD lpcchClass, PFILETIME lpftLastWriteTime ); 

LpcchName पॉइंटर को वर्ण में बफर साइज वाले वेरिएबल को इंगित करना चाहिए: "वैरिएबल का पॉइंटर जो वर्णों में lpClass पैरामीटर द्वारा निर्दिष्ट बफर के आकार को निर्दिष्ट करता है"। उपकुंजी सरणी आकार 512 बाइट्स है और wchar_t प्रकार के 256 वर्णों को संग्रहीत कर सकता है (विंडोज़ में, wchar_t 2 बाइट्स है)। यह 256 है जिसे फ़ंक्शन को पास किया जाना चाहिए। इसके बजाय, 512 को 2 से गुणा किया जाता है और हमें 1024 मिलते हैं।

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

 DWORD cch_subkeyname = sizeof(subkeyname) / sizeof(subkeyname[0]); 

वैसे, cch_keyclass चर के मान का मूल्यांकन करते समय एक ही त्रुटि होती है।

वर्णित त्रुटि संभावित रूप से बफर अतिप्रवाह को जन्म दे सकती है। ऐसे सभी अंशों को निश्चित रूप से सुधारा जाना चाहिए:

• V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 556
• V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 572
• V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 621
• V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 622
• V531 यह अजीब है कि एक आकार () ऑपरेटर को आकार से गुणा किया जाता है ()। cmGlobalVisualStudioGenerator.cxx 649

V595 nullptr के खिलाफ सत्यापित होने से पहले 'this-> BuildFileStream' पॉइंटर का उपयोग किया गया था। लाइनों की जाँच करें: 133, 134. cmMakefileTargetGenerator.cxx 133

 void cmMakefileTargetGenerator::CreateRuleFile() { .... this->BuildFileStream->SetCopyIfDifferent(true); if (!this->BuildFileStream) { return; } .... } 

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

• V595 nullptr के खिलाफ सत्यापित होने से पहले 'इस-> फ्लैगफाइलस्ट्रीम' पॉइंटर का उपयोग किया गया था। चेक लाइन: 303, 304. cmMakefileTargetGenerator.cxx 303

V614 Uninitialized पॉइंटर 'str' का इस्तेमाल किया। cmVSSetupHelper.h 80

 class SmartBSTR { public: SmartBSTR() { str = NULL; } SmartBSTR(const SmartBSTR& src) { if (src.str != NULL) { str = ::SysAllocStringByteLen((char*)str, ::SysStringByteLen(str)); } else { str = ::SysAllocStringByteLen(NULL, 0); } } .... private: BSTR str; }; 

विश्लेषक ने असंगठित स्ट्रेट पॉइंटर के उपयोग का पता लगाया। यह एक साधारण टाइपो के कारण दिखाई दिया। SysAllocStringByteLen फ़ंक्शन को कॉल करते समय , किसी को src.str सूचक का उपयोग करना चाहिए था।

V557 ऐरे ओवररन संभव है। 'लैंसिमबोल' इंडेक्स का मान 28 तक पहुंच सकता है

 static int64_t expand(struct archive_read *a, int64_t end) { .... if ((lensymbol = read_next_symbol(a, &rar->lengthcode)) < 0) goto bad_data; if (lensymbol > (int)(sizeof(lengthbases)/sizeof(lengthbases[0]))) goto bad_data; if (lensymbol > (int)(sizeof(lengthbits)/sizeof(lengthbits[0]))) goto bad_data; len = lengthbases[lensymbol] + 2; if (lengthbits[lensymbol] > 0) { if (!rar_br_read_ahead(a, br, lengthbits[lensymbol])) goto truncated_data; len += rar_br_bits(br, lengthbits[lensymbol]); rar_br_consume(br, lengthbits[lensymbol]); } .... } 

कोड का यह टुकड़ा एक साथ कई समस्याओं को छुपाता है। जब लम्बाई और लम्बाई सरणियों तक पहुँचते हैं, तो एक सरणी सूचकांक सीमा से बाहर जा सकता है, क्योंकि डेवलपर्स ने ऊपर '> =' के बजाय '>' ऑपरेटर लिखा था। यह चेक एक अस्वीकार्य मूल्य को याद करने लगा। यहां हमारे पास ऑफ-द-वन एरर नामक क्लासिक एरर पैटर्न के अलावा कुछ नहीं है।

गैर-मान्य इंडेक्स द्वारा सरणी एक्सेस संचालन की पूरी सूची यहां दी गई है:

• V557 ऐरे ओवररन संभव है। 'लैंसिमबोल' इंडेक्स का मान 28 तक पहुंच सकता है
• V557 ऐरे ओवररन संभव है। 'लैंसिमबोल' इंडेक्स का मान 28 तक पहुंच सकता है
• V557 ऐरे ओवररन संभव है। 'लैंसिमबोल' इंडेक्स का मान 28 तक पहुंच सकता है
• V557 ऐरे ओवररन संभव है। 'लैंसिमबोल' इंडेक्स का मान 28 तक पहुंच सकता है
• V557 ऐरे ओवररन संभव है। 'ऑफसाइंबोल' इंडेक्स का मान 60 तक पहुंच सकता है

स्मृति रिसाव

V773 फ़ंक्शन को 'testRun' पॉइंटर जारी किए बिना बाहर किया गया था। एक स्मृति रिसाव संभव है। cmCTestMultiProcessHandler.cxx 193

 void cmCTestMultiProcessHandler::FinishTestProcess(cmCTestRunTest* runner, bool started) { .... delete runner; if (started) { this->StartNextTests(); } } bool cmCTestMultiProcessHandler::StartTestProcess(int test) { .... cmCTestRunTest* testRun = new cmCTestRunTest(*this); // <= .... if (testRun->StartTest(this->Completed, this->Total)) { return true; // <= } } this->FinishTestProcess(testRun, false); // <= return false; } 

विश्लेषक ने स्मृति रिसाव का पता लगाया। TestRun पॉइंटर द्वारा मेमोरी जारी नहीं की जाती है, यदि फ़ंक्शन testRun-> StartTest रिटर्न सही है । किसी अन्य कोड शाखा को निष्पादित करते समय, यह मेमोरी फ़ंक्शन में जारी हो जाती है-> FinishTestProcess।

संसाधन रिसाव

V773 'fd' हैंडल द्वारा संदर्भित फ़ाइल को बंद किए बिना फ़ंक्शन को बाहर किया गया था। एक संसाधन रिसाव संभव है। rhash.c 450

 RHASH_API int rhash_file(....) { FILE* fd; rhash ctx; int res; hash_id &= RHASH_ALL_HASHES; if (hash_id == 0) { errno = EINVAL; return -1; } if ((fd = fopen(filepath, "rb")) == NULL) return -1; if ((ctx = rhash_init(hash_id)) == NULL) return -1; // <= fclose(fd); ??? res = rhash_file_update(ctx, fd); fclose(fd); rhash_final(ctx, result); rhash_free(ctx); return res; } 

शर्तों में अजीब तर्क

V590 '* s! =' '0' && * s == '' 'अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। संग्रह_ cmdline.c 76

 static ssize_t get_argument(struct archive_string *as, const char *p) { const char *s = p; archive_string_empty(as); /* Skip beginning space characters. */ while (*s != '\0' && *s == ' ') s++; .... } 

* अशक्त के साथ चरित्र की तुलना बेमानी है। लूप की स्थिति केवल इस बात पर निर्भर करती है कि चरित्र अंतरिक्ष के बराबर है या नहीं। यह एक त्रुटि नहीं है, लेकिन कोड की एक अनावश्यक जटिलता है।

V592 दो बार कोष्ठक द्वारा अभिव्यक्ति संलग्न किया गया था: ((अभिव्यक्ति))। कोष्ठक की एक जोड़ी अनावश्यक है या गलत धारणा मौजूद है। cmCTestTestHandler.cxx 899

 void cmCTestTestHandler::ComputeTestListForRerunFailed() { this->ExpandTestsToRunInformationForRerunFailed(); ListOfTests finalList; int cnt = 0; for (cmCTestTestProperties& tp : this->TestList) { cnt++; // if this test is not in our list of tests to run, then skip it. if ((!this->TestsToRun.empty() && std::find(this->TestsToRun.begin(), this->TestsToRun.end(), cnt) == this->TestsToRun.end())) { continue; } tp.Index = cnt; finalList.push_back(tp); } .... } 

विश्लेषक चेतावनी देता है कि नकारात्मक संचालन को संभवतः कोष्ठक से बाहर ले जाना चाहिए। ऐसा लगता है कि यहां ऐसा कोई बग नहीं है - बस अनावश्यक डबल ब्रैकेट। लेकिन सबसे अधिक संभावना है, कोड में एक तर्क त्रुटि है।

जारी ऑपरेटर को केवल उस स्थिति में निष्पादित किया जाता है यदि परीक्षण की सूची यह-> टेस्टटाउन खाली नहीं है और cnt इसमें अनुपस्थित है। यह मानना ​​उचित है कि यदि परीक्षण सूची खाली है, तो उसी कार्रवाई की आवश्यकता है। सबसे शायद, हालत इस प्रकार होनी चाहिए:

 if (this->TestsToRun.empty() || std::find(this->TestsToRun.begin(), this->TestsToRun.end(), cnt) == this->TestsToRun.end()) { continue; } 

V592 दो बार कोष्ठक द्वारा अभिव्यक्ति संलग्न किया गया था: ((अभिव्यक्ति))। कोष्ठक की एक जोड़ी अनावश्यक है या गलत धारणा मौजूद है। cmMessageCommand.cxx 73

 bool cmMessageCommand::InitialPass(std::vector<std::string> const& args, cmExecutionStatus&) { .... } else if (*i == "DEPRECATION") { if (this->Makefile->IsOn("CMAKE_ERROR_DEPRECATED")) { fatal = true; type = MessageType::DEPRECATION_ERROR; level = cmake::LogLevel::LOG_ERROR; } else if ((!this->Makefile->IsSet("CMAKE_WARN_DEPRECATED") || this->Makefile->IsOn("CMAKE_WARN_DEPRECATED"))) { type = MessageType::DEPRECATION_WARNING; level = cmake::LogLevel::LOG_WARNING; } else { return true; } ++i; } .... } 

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

V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। cmCTestRunTest.cxx 151

 bool cmCTestRunTest::EndTest(size_t completed, size_t total, bool started) { .... } else if ((success && !this->TestProperties->WillFail) || (!success && this->TestProperties->WillFail)) { this->TestResult.Status = cmCTestTestHandler::COMPLETED; outputStream << " Passed "; } .... } 

यह कोड सरल हो सकता है। एक निम्नलिखित तरीके से सशर्त अभिव्यक्ति को फिर से लिख सकता है:

 } else if (success != this->TestProperties->WillFail) { this->TestResult.Status = cmCTestTestHandler::COMPLETED; outputStream << " Passed "; } 

सरल बनाने के लिए कुछ और जगहें:

• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A && B) || ((A &&! B) 'अभिव्यक्ति' बूल (ए) == बूल (बी) 'अभिव्यक्ति के बराबर है। cmCTestTestHandler.cxx 702
• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। digest_sspi.c 443
• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। tcp.c 1295
• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। testDynamicLoader.cxx 58
• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। testDynamicLoader.cxx 65
• V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। testDynamicLoader.cxx 72

विभिन्न चेतावनियाँ

V523 'तत्कालीन' कथन बाद के कोड के टुकड़े के बराबर है। आर्काइव_ड्रेड_बिल्डरफॉर्म_आरसी 415

 static int _ar_read_header(struct archive_read *a, struct archive_entry *entry, struct ar *ar, const char *h, size_t *unconsumed) { .... /* * "__.SYMDEF" is a BSD archive symbol table. */ if (strcmp(filename, "__.SYMDEF") == 0) { archive_entry_copy_pathname(entry, filename); /* Parse the time, owner, mode, size fields. */ return (ar_parse_common_header(ar, entry, h)); } /* * Otherwise, this is a standard entry. The filename * has already been trimmed as much as possible, based * on our current knowledge of the format. */ archive_entry_copy_pathname(entry, filename); return (ar_parse_common_header(ar, entry, h)); } 

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

V535 चर 'i' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। चेक लाइन: 2220, 2241। मल्टीसी 2241

 static CURLMcode singlesocket(struct Curl_multi *multi, struct Curl_easy *data) { .... for(i = 0; (i< MAX_SOCKSPEREASYHANDLE) && // <= (curraction & (GETSOCK_READSOCK(i) | GETSOCK_WRITESOCK(i))); i++) { unsigned int action = CURL_POLL_NONE; unsigned int prevaction = 0; unsigned int comboaction; bool sincebefore = FALSE; s = socks[i]; /* get it from the hash */ entry = sh_getentry(&multi->sockhash, s); if(curraction & GETSOCK_READSOCK(i)) action |= CURL_POLL_IN; if(curraction & GETSOCK_WRITESOCK(i)) action |= CURL_POLL_OUT; actions[i] = action; if(entry) { /* check if new for this transfer */ for(i = 0; i< data->numsocks; i++) { // <= if(s == data->sockets[i]) { prevaction = data->actions[i]; sincebefore = TRUE; break; } } } .... } 

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

V519 'टैगस्ट्रिंग' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 84, 86. cmCPackLog.cxx 86

 void cmCPackLog::Log(int tag, const char* file, int line, const char* msg, size_t length) { .... if (tag & LOG_OUTPUT) { output = true; display = true; if (needTagString) { if (!tagString.empty()) { tagString += ","; } tagString = "VERBOSE"; } } if (tag & LOG_WARNING) { warning = true; display = true; if (needTagString) { if (!tagString.empty()) { tagString += ","; } tagString = "WARNING"; } } .... } 

सभी स्थानों में एक नए मान के साथ टैगस्ट्रिंग चर अधिलेखित है। यह कहना मुश्किल है कि मुद्दा क्या है या उन्होंने ऐसा क्यों किया। शायद, '=' और '+' = ऑपरेटरों को मैला कर दिया गया था।

ऐसे स्थानों की पूरी सूची:

• V519 'टैगस्ट्रिंग' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 94, 96. cmCPackLog.cxx 96
• V519 'टैगस्ट्रिंग' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। लाइनों की जाँच करें: 104, 106. cmCPackLog.cxx 106
• V519 'टैगस्ट्रिंग' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। लाइनों की जाँच करें: 114, 116. cmCPackLog.cxx 116
• V519 'टैगस्ट्रिंग' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 125, 127. cmCPackLog.cxx 127

V519 'aes-> aes_set' चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 4052, 4054। आर्काइव_स्ट्रिंग। 4054

 int archive_mstring_copy_utf8(struct archive_mstring *aes, const char *utf8) { if (utf8 == NULL) { aes->aes_set = 0; // <= } aes->aes_set = AES_SET_UTF8; // <= .... return (int)strlen(utf8); } 

AES_SET_UTF8 मान की जबरन सेटिंग संदिग्ध लगती है। मुझे लगता है कि ऐसा कोड किसी भी डेवलपर को भ्रमित करेगा, जो इस टुकड़े को परिष्कृत करने के लिए आता है।

इस कोड को दूसरी जगह कॉपी किया गया था:

• V519 'aes-> aes_set' चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 4066, 4068। आर्काइव_स्ट्रिंग। 4068

CMake पर एक परियोजना में कीड़े कैसे खोजें

इस खंड में, मैं आपको संक्षेप में बताऊंगा कि पीवीएस-स्टूडियो के साथ सीएमके परियोजनाओं को एक-दो-तीन के रूप में आसान कैसे जांचें।

विंडोज / विजुअल स्टूडियो

विज़ुअल स्टूडियो के लिए, आप CMake GUI या निम्न कमांड का उपयोग कर एक प्रोजेक्ट फ़ाइल उत्पन्न कर सकते हैं:

 cmake -G "Visual Studio 15 2017 Win64" .. 

अगला, आप .sln फ़ाइल खोल सकते हैं और विज़ुअल स्टूडियो के लिए प्लगइन का उपयोग करके परियोजना की जांच कर सकते हैं।

लिनक्स / macOS

इन सिस्टम पर जाँच के लिए फ़ाइल compile_commands.json का उपयोग किया जाता है। वैसे, यह विभिन्न बिल्ड सिस्टम में उत्पन्न किया जा सकता है। यह आप इसे CMake में कैसे करते हैं:

 cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On .. 

अंतिम बात करने के लिए .json फ़ाइल के साथ निर्देशिका में विश्लेषक चलाया जाता है:

 pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic -o /path/to/project.log -e /path/to/exclude-path -j<N> 

हमने सीएमके परियोजनाओं के लिए एक मॉड्यूल भी विकसित किया है। कुछ लोग इसका इस्तेमाल करना पसंद करते हैं। CMake मॉड्यूल और इसके उपयोग के उदाहरण GitHub पर हमारे भंडार में पाए जा सकते हैं: pvs-studio-cmake-example ।

निष्कर्ष

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

यदि आपको विश्लेषक परिणाम पसंद हैं, लेकिन आपकी परियोजना C और C ++ में नहीं लिखी गई है, तो मैं याद दिलाना चाहूंगा कि विश्लेषक C # और Java में परियोजनाओं के विश्लेषण का भी समर्थन करता है। आप इस पृष्ठ पर जाकर अपनी परियोजना के विश्लेषक का परीक्षण कर सकते हैं।