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 गुना बड़ा मूल्य प्राप्त किया। आइए हम बताते हैं कि यह "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 वर्णों को संग्रहीत करने में सक्षम है (Windows wchar_t में यह 2 बाइट्स है)। यह मान 256 है और इसे फ़ंक्शन में पास किया जाना चाहिए। इसके बजाय, 1024 प्राप्त करने के लिए 512 को 2 से गुणा किया जाता है।

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

 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; } .... } 

यह-> BuildFileStream पॉइंटर सत्यापन जांच से ठीक पहले डिरेल किया गया है । क्या यह वास्तव में कोई समस्या पैदा कर रहा था? नीचे ऐसी जगह का एक और उदाहरण दिया गया है। इसे कार्बन पेपर के ठीक नीचे बनाया गया है। लेकिन वास्तव में, बहुत सारे वी 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; }; 

विश्लेषक ने असंगठित सूचक 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 रिटर्न सही है । जब कोड की किसी अन्य शाखा को निष्पादित किया जाता है, तो testRun पॉइंटर का उपयोग करके मेमोरी को इस-> 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++; .... } 

टर्मिनल शून्य के साथ * 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); } .... } 

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

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

 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

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

निष्कर्ष

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

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

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