आरओटी कोड का विश्लेषण, वैज्ञानिक डेटा विश्लेषण फ्रेमवर्क

जब स्टॉकहोम 118 वें नोबेल सप्ताह का आयोजन कर रहा था, मैं हमारे कार्यालय में बैठा था, जहाँ हम PVS-Studio स्थैतिक विश्लेषक विकसित करते हैं, जो ROOT प्रोजेक्ट की विश्लेषण समीक्षा पर काम कर रहा है, जो एक बड़ा-डाटा प्रोसेसिंग ढांचा है, जिसका उपयोग वैज्ञानिक अनुसंधान में किया जाता है। यह कोड निश्चित रूप से पुरस्कार नहीं जीत सकता है, लेकिन लेखक निश्चित रूप से सबसे दिलचस्प दोषों की विस्तृत समीक्षा के साथ-साथ अपने स्वयं के प्रोजेक्ट को पूरी तरह से जांचने के लिए एक निशुल्क लाइसेंस की गणना कर सकते हैं।

परिचय

जड़ एक मॉड्यूलर वैज्ञानिक सॉफ्टवेयर टूलकिट है। यह बड़े डेटा प्रोसेसिंग, सांख्यिकीय विश्लेषण, दृश्य और भंडारण से निपटने के लिए आवश्यक सभी कार्यक्षमता प्रदान करता है। यह मुख्य रूप से C ++ में लिखा गया है। ROOT का जन्म CERN में उच्च-ऊर्जा भौतिकी पर शोध के अंत में हुआ था। हर दिन, हजारों भौतिक विज्ञानी अपने डेटा का विश्लेषण करने या सिमुलेशन करने के लिए ROOT अनुप्रयोगों का उपयोग करते हैं।

पीवीएस-स्टूडियो सी, सी ++, सी #, और जावा में लिखे कार्यक्रमों के स्रोत कोड में सॉफ़्टवेयर बग्स और संभावित कमजोरियों का पता लगाने के लिए एक उपकरण है। यह 64-बिट विंडोज, लिनक्स और मैकओएस पर चलता है और 32-बिट, 64-बिट और एम्बेडेड एआरएम प्लेटफार्मों के लिए लिखे गए स्रोत कोड का विश्लेषण कर सकता है।

एक नए निदान की शुरुआत

V1046 बूल का असुरक्षित उपयोग 'और' int 'एक साथ ऑपरेशन' और = 'में। GSLMultiRootFinder.h 175

int AddFunction(const ROOT::Math::IMultiGenFunction & func) { ROOT::Math::IMultiGenFunction * f = func.Clone(); if (!f) return 0; fFunctions.push_back(f); return fFunctions.size(); } template<class FuncIterator> bool SetFunctionList( FuncIterator begin, FuncIterator end) { bool ret = true; for (FuncIterator itr = begin; itr != end; ++itr) { const ROOT::Math::IMultiGenFunction * f = *itr; ret &= AddFunction(*f); } return ret; } 

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

उम्मीदें। SetFunctionList फ़ंक्शन एक पुनरावृत्त सूची का पता लगाता है । यदि कम से कम एक पुनरावृत्त अमान्य है, तो फ़ंक्शन गलत है , या अन्यथा सत्य है।

हकीकत। SetFunctionList फ़ंक्शन मान्य पुनरावृत्तियों के लिए भी गलत वापस आ सकता है। आइए जानें इसका कारण। AddFunction फ़ंक्शन fFunctions सूची में मान्य पुनरावृत्तियों की संख्या लौटाता है। यही है, गैर-शून्य पुनरावृत्तियों को जोड़ने से सूची आकार में वृद्धि के कारण होगी: 1, 2, 3, 4, और इसी तरह। यह वह जगह है जहाँ बग खेलने में आता है:

 ret &= AddFunction(*f); 

चूंकि फ़ंक्शन बूल की बजाय टाइप इंट का मान लौटाता है, इसलिए '& =' ऑपरेशन भी मानों के लिए गलत वापस आ जाएगा, क्योंकि एक समान संख्या का कम से कम महत्वपूर्ण बिट हमेशा शून्य पर सेट होता है। यह कैसे एक सूक्ष्म बग सेटफंक्शंस के रिटर्न मूल्य को तब भी तोड़ सकता है जब इसके तर्क मान्य हों।

सशर्त अभिव्यक्तियों में त्रुटियां

V501 बाईं और 'और&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: मॉड्यूल और& मॉड्यूल rootcling_impl.cxx 3650

 virtual void HandleDiagnostic(....) override { .... bool isROOTSystemModuleDiag = module && ....; bool isSystemModuleDiag = module && module && module->IsSystem; if (!isROOTSystemModuleDiag && !isSystemModuleDiag) fChild->HandleDiagnostic(DiagLevel, Info); .... } 

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

V501 समान उप-अभिव्यक्तियाँ हैं 'strchr (fHostAuth-> GetHost (),' * ')' बाईं ओर 'और' के दाईं ओर ' ऑपरेटर। TAuthenticate.cxx 300

 TAuthenticate::TAuthenticate(TSocket *sock, const char *remote, const char *proto, const char *user) { .... // If generic THostAuth (ie with wild card or user == any) // make a personalized memory copy of this THostAuth if (strchr(fHostAuth->GetHost(),'*') || strchr(fHostAuth->GetHost(),'*') || fHostAuth->GetServer() == -1 ) { fHostAuth = new THostAuth(*fHostAuth); fHostAuth->SetHost(fqdn); fHostAuth->SetUser(checkUser); fHostAuth->SetServer(servtype); } .... } 

FHostAuth-> GetHost () स्ट्रिंग को दो बार '*' वर्ण के लिए स्कैन किया गया है। इनमें से एक चेक शायद 'देखने के लिए था?' इन दो पात्रों के रूप में चरित्र आम तौर पर विभिन्न वाइल्डकार्ड मास्क निर्दिष्ट करने के लिए उपयोग किए जाते हैं।

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइन: 163, 165. TProofMonSenderML.cxx 163

 Int_t TProofMonSenderML::SendSummary(TList *recs, const char *id) { .... if (fSummaryVrs == 0) { if ((dsn = recs->FindObject("dataset"))) recs->Remove(dsn); } else if (fSummaryVrs == 0) { // Only the first records xrecs = new TList; xrecs->SetOwner(kFALSE); TIter nxr(recs); TObject *o = 0; while ((o = nxr())) { if (!strcmp(o->GetName(), "vmemmxw")) break; xrecs->Add(o); } } .... } 

FSummaryVrs चर की तुलना शून्य से दो बार की जाती है, इसलिए निष्पादन कभी भी अन्य-यदि शाखा में कोड तक नहीं पहुंचता है। और वहाँ कोड का एक सा है ...

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। TKDTree.cxx 805

 template <typename Index, typename Value> void TKDTree<Index, Value>::UpdateRange(....) { .... if (point[fAxis[inode]]<=fValue[inode]){ //first examine the node that contains the point UpdateRange(GetLeft(inode),point, range, res); UpdateRange(GetRight(inode),point, range, res); } else { UpdateRange(GetLeft(inode),point, range, res); UpdateRange(GetRight(inode),point, range, res); } .... } 

कोड का एक ही ब्लॉक, जो एक कॉपी-पेस्ट क्लोन है, को निष्पादित किया जाता है, चाहे वह कोई भी शर्त हो। मुझे लगता है कि बाएँ और दाएँ शब्दों के बीच एक भ्रम है।

परियोजना उस तरह के संदिग्ध स्थानों से भरी है:

• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। TContainerConverters.cxx 51
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। TWebFile.cxx 1310
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। MethodMLP.cxx 423
• V523 'तत्कालीन' कथन 'और' कथन के बराबर है। RooAbsCategory.cxx 394

V547 अभिव्यक्ति '! File_name_value.empty ()' हमेशा गलत है। चयनसंग्रह .xx 1423

 bool SelectionRules::AreAllSelectionRulesUsed() const { for(auto&& rule : fClassSelectionRules){ .... std::string file_name_value; if (!rule.GetAttributeValue("file_name", file_name_value)) file_name_value.clear(); if (!file_name_value.empty()) { // <= // don't complain about defined_in rules continue; } const char* attrName = nullptr; const char* attrVal = nullptr; if (!file_name_value.empty()) { // <= attrName = "file name"; attrVal = file_name_value.c_str(); } else { attrName = "class"; if (!name.empty()) attrVal = name.c_str(); } ROOT::TMetaUtils::Warning(0,"Unused %s rule: %s\n", attrName, attrVal); } .... } 

यह शायद एक बग नहीं है; विश्लेषक को केवल कुछ कोड मिले जिन्हें सरल बनाया जा सकता है। चूंकि file_name_value.empty () का रिटर्न मान पहले से ही लूप की शुरुआत में चेक किया गया है, दूसरा डुप्लिकेट चेक हटाया जा सकता है, इस प्रकार अनावश्यक कोड की एक अच्छी मात्रा को फेंक दिया जाता है।

V590 'का निरीक्षण करने पर विचार करें! File1 || c <= 0 || c == '*' || c! = '(' 'एक्सप्रेशन। एक्सप्रेशन ज़रूरत से ज़्यादा है या इसमें मिसप्रिंट है। TTabCom.cxx 840

 TString TTabCom::DetermineClass(const char varName[]) { .... c = file1.get(); if (!file1 || c <= 0 || c == '*' || c != '(') { Error("TTabCom::DetermineClass", "variable \"%s\" not defined?", varName); goto cleanup; } .... } 

यहाँ विश्लेषक द्वारा बताई गई सशर्त अभिव्यक्ति का समस्या भाग है:

 if (.... || c == '*' || c != '(') { .... } 

तारांकन वर्ण के लिए जाँच स्थिति के परिणाम को प्रभावित नहीं करेगी। यह भाग '(') के अलावा किसी भी वर्ण के लिए हमेशा सत्य होगा। आप एक सत्य सारणी बनाकर आसानी से इसे अपने लिए देख सकते हैं।

अजीब तर्क के साथ शर्तों के बारे में दो और चेतावनियाँ:

• V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। TFile.cxx 3963
• V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। TStreamerInfoActions.cxx 3084

V593 'ए = बी <सी' प्रकार की अभिव्यक्ति की समीक्षा करने पर विचार करें। अभिव्यक्ति की गणना निम्न प्रकार से की जाती है: 'ए = (बी <सी)'। TProofServ.cxx 1903

 Int_t TProofServ::HandleSocketInput(TMessage *mess, Bool_t all) { .... if (Int_t ret = fProof->AddWorkers(workerList) < 0) { Error("HandleSocketInput:kPROOF_GETSLAVEINFO", "adding a list of worker nodes returned: %d", ret); } .... } 

यह बग केवल कार्यक्रम के दोषपूर्ण व्यवहार के मामले में खुद को प्रकट करता है। रिट चर को AddWorkers फ़ंक्शन के रिटर्न कोड को संग्रहीत करना है और त्रुटि स्थिति के मामले में लॉग में उस मान को लिखना है। लेकिन यह इरादा के अनुसार काम नहीं करता है। मूल्यांकन के वांछित क्रम के लिए स्थिति में अतिरिक्त कोष्ठकों का अभाव है। रिट चर वास्तव में क्या स्टोर करता है रिटर्न कोड नहीं है, लेकिन तार्किक तुलना का परिणाम है, अर्थात 0 या 1।

इसी तरह की एक और समस्या:

• V593 'ए = बी <सी' प्रकार की अभिव्यक्ति की समीक्षा करने पर विचार करें। अभिव्यक्ति की गणना निम्न प्रकार से की जाती है: 'ए = (बी <सी)'। TProofServ.cxx 3897

V768 गणना निरंतर 'kCostComplexityPruning' का उपयोग बूलियन-प्रकार के एक चर के रूप में किया जाता है। MethodDT.cxx 283

 enum EPruneMethod {kExpectedErrorPruning=0, kCostComplexityPruning, kNoPruning}; void TMVA::MethodDT::ProcessOptions() { .... if (fPruneStrength < 0) fAutomatic = kTRUE; else fAutomatic = kFALSE; if (fAutomatic && fPruneMethod==!DecisionTree::kCostComplexityPruning){ Log() << kFATAL << "Sorry automatic pruning strength determination is ...." << Endl; } .... } 

हम्म ... निरंतर मूल्य kCostComplexityPruning को नकारात्मक क्यों? मुझे लगता है कि नकारात्मक चरित्र एक टाइपो है, जो अब निष्पादन तर्क को विकृत करता है।

सूचक हैंडलिंग त्रुटियों

V522 अशक्त सूचक 'पूर्व' की Dereferencing हो सकती है। TSynapse.cxx 61

 void TSynapse::SetPre(TNeuron * pre) { if (pre) { Error("SetPre","this synapse is already assigned to a pre-neuron."); return; } fpre = pre; pre->AddPost(this); } 

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

मुझे लगता है कि इस स्निपेट को निम्नानुसार तय किया जाना चाहिए:

 void TSynapse::SetPre(TNeuron * pre) { if (fpre) { Error("SetPre","this synapse is already assigned to a pre-neuron."); return; } fpre = pre; pre->AddPost(this); } 

यह, हालांकि, फ़ंक्शन के लिए एक शून्य पॉइंटर को पारित करने से नहीं रोक सकता है, लेकिन कम से कम यह संस्करण मूल रूप से एक से अधिक तार्किक है।

इस कोड का थोड़ा संशोधित क्लोन दूसरे स्थान पर पाया जा सकता है:

• V522 अशक्त सूचक 'पद' की Dereferencing हो सकती है। TSynapse.cxx 74

N5ptr के खिलाफ सत्यापित होने से पहले V595 'N' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 484, 488. स्कैनर। 48xx 484

 bool RScanner::shouldVisitDecl(clang::NamedDecl *D) { if (auto M = D->getOwningModule()) { // <= 2 return fInterpreter.getSema().isModuleVisible(M); } return true; } bool RScanner::VisitNamespaceDecl(clang::NamespaceDecl* N) { if (fScanType == EScanType::kOnePCM) return true; if (!shouldVisitDecl(N)) // <= 1 return true; if((N && N->isImplicit()) || !N){ // <= 3 return true; } .... } 

यह कोड का एक बेहद खतरनाक टुकड़ा है! N पॉइंटर को पहली बार डिरेल होने से पहले नल के लिए चेक नहीं किया गया है। क्या अधिक है, आप इसे यहाँ नहीं देख सकते क्योंकि dereference कंधों के बीच में होता है।

यह निदान पारंपरिक रूप से प्रासंगिक चेतावनियों का एक समूह उत्पन्न करता है। यहाँ कुछ उदाहरण दिए गए हैं:

• V595 nullptr के खिलाफ सत्यापित होने से पहले 'फ़ाइल' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 141, 153. TFileCacheRead.cxx 141
• V595 nullptr के खिलाफ सत्यापित होने से पहले 'fFree' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 2029, 2038. TFile.cxx 2029
• N5ptr के खिलाफ सत्यापित होने से पहले V595 'tbuf' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 586, 591. TGText.cxx 586
• V595 nullptr के खिलाफ सत्यापित होने से पहले 'fPlayer' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 3425, 3430. TProof.cxx 3425
• V595 nullptr के खिलाफ सत्यापित होने से पहले 'gProofServ' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 1192, 1194. TProofPlayer.cxx 1192
• V595 nullptr के खिलाफ सत्यापित होने से पहले 'projDataTmp' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 791, 804. RooSimultaneous.cxx 791

अगले एक बग नहीं है, लेकिन यह अभी तक एक और उदाहरण है कि मैक्रोज़ कैसे दोषपूर्ण या निरर्थक कोड लिखने के लिए प्रोत्साहित करते हैं ।

V571 आवर्ती जाँच। The if (fCanvasImp) ’स्थिति पहले ही लाइन 799 में सत्यापित हो गई थी। TCanvas.cxx 800

 #define SafeDelete(p) { if (p) { delete p; p = 0; } } void TCanvas::Close(Option_t *option) { .... if (fCanvasImp) SafeDelete(fCanvasImp); .... } 

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

एरर हैंडलिंग एरर

V519 'लाइन [कर्सर]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 352, 353। Editor.cpp 353

 size_t find_last_non_alnum(const std::string &str, std::string::size_type index = std::string::npos) { .... char tmp = Line.GetText()[Cursor]; Line[Cursor] = Line[Cursor - 1]; Line[Cursor] = tmp; .... } 

एलिमेंट लाइन [कर्सर] को एक नया मान दिया गया है, जो फिर तुरंत अधिलेखित हो जाता है। यह सही नहीं लगता ...

V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 130

 bool BasicMinimizer::SetVariableValue(unsigned int ivar, double val) { if (ivar > fValues.size() ) return false; fValues[ivar] = val; return true; } 

एरे इंडेक्स की जाँच करते समय यह गलती करना एक हालिया चलन है; हम इसे लगभग हर तीसरे प्रोजेक्ट में देखते हैं। एक लूप के अंदर एक सरणी में अनुक्रमण करना आसान है - आप आमतौर पर सरणी के आकार के साथ सूचकांक की तुलना करने के लिए '<' ऑपरेटर का उपयोग करते हैं - ऊपर दिखाए गए चेक की तरह '> =' ऑपरेटर की आवश्यकता होती है, न कि '>'। अन्यथा आप सरणी के बाउंड से परे एक तत्व को अनुक्रमित करने का जोखिम उठाते हैं।

इस बग को पूरे कोड में कुछ समय के लिए क्लोन किया गया था:

• V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 186
• V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 194
• V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 209
• V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 215
• V557 ऐरे ओवररन संभव है। 'Ivar' इंडेक्स सरणी बाउंड से परे इशारा कर रहा है। BasicMinimizer.cxx 230

V621 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। यह संभव है कि लूप को गलत तरीके से निष्पादित किया जाएगा या बिल्कुल भी निष्पादित नहीं किया जाएगा। TDataMember.cxx 554

 Int_t TDataMember::GetArrayDim() const { if (fArrayDim<0 && fInfo) { R__LOCKGUARD(gInterpreterMutex); TDataMember *dm = const_cast<TDataMember*>(this); dm->fArrayDim = gCling->DataMemberInfo_ArrayDim(fInfo); // fArrayMaxIndex should be zero if (dm->fArrayDim) { dm->fArrayMaxIndex = new Int_t[fArrayDim]; for(Int_t dim = 0; dim < fArrayDim; ++dim) { dm->fArrayMaxIndex[dim] = gCling->DataMemberInfo_MaxIndex(fInfo,dim); } } } return fArrayDim; } 

लूप के लिए , डेवलपर्स का स्पष्ट रूप से मंद चर की तुलना dm-> fArrayDim के बजाय fArrayDim से करना था । FArrayDim का मान ऋणात्मक है, जो फ़ंक्शन की शुरुआत में स्थिति की गारंटी देता है। नतीजतन, यह लूप कभी भी निष्पादित नहीं करेगा।

V767 लूप के अंदर एक स्थिर सूचकांक द्वारा 'करंट' एरे के तत्व तक संदिग्ध पहुंच। TClingUtils.cxx 3082

 llvm::StringRef ROOT::TMetaUtils::DataMemberInfo__ValidArrayIndex(....) { .... while (current!=0) { // Check the token if (isdigit(current[0])) { for(i=0;i<strlen(current);i++) { if (!isdigit(current[0])) { if (errstr) *errstr = current; if (errnum) *errnum = NOT_INT; return llvm::StringRef(); } } } else { // current token is not a digit .... } .... } .... } 

यह कोड कुछ स्ट्रिंग को पार्स और जाँच रहा है। यदि वर्तमान स्ट्रिंग के पहले वर्ण (यानी इंडेक्स 0 पर) को एक संख्या के रूप में मान्यता दी गई है, तो लूप सभी शेष वर्णों को पीछे छोड़ देगा, यह सुनिश्चित करने के लिए कि सभी संख्याएं हैं। ठीक है, कम से कम यह विचार है। समस्या यह है, आई काउंटर का उपयोग लूप में नहीं किया जाता है। शर्त को फिर से लिखा जाना चाहिए ताकि यह वर्तमान [i] के बजाय वर्तमान [i] की जांच करे।

स्मृति रिसाव

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

 void TDataMember::Init(bool afterReading) { .... TList *optionlist = new TList(); //storage for options strings for (i=0;i<token_cnt;i++) { if (strstr(tokens[i],"Items")) { ptr1 = R__STRTOK_R(tokens[i], "()", &rest); if (ptr1 == 0) { Fatal("TDataMember","Internal error, found \"Items....",GetTitle()); return; } ptr1 = R__STRTOK_R(nullptr, "()", &rest); if (ptr1 == 0) { Fatal("TDataMember","Internal error, found \"Items....",GetTitle()); return; } .... } .... } .... // dispose of temporary option list... delete optionlist; .... } 

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

फिर से याद करना

V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'x' बफर को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। TMD5.cxx 366

 void TMD5::Transform(UInt_t buf[4], const UChar_t in[64]) { UInt_t a, b, c, d, x[16]; .... // Zero out sensitive information memset(x, 0, sizeof(x)); } 

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

विविध

V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। LogLikelihoodFCN.h 108

 LogLikelihoodFCN & operator = (const LogLikelihoodFCN & rhs) { SetData(rhs.DataPtr() ); SetModelFunction(rhs.ModelFunctionPtr() ); fNEffPoints = rhs.fNEffPoints; fGrad = rhs.fGrad; fIsExtended = rhs.fIsExtended; fWeight = rhs.fWeight; fExecutionPolicy = rhs.fExecutionPolicy; } 

ओवरलोड ऑपरेटर का कोई वापसी मूल्य नहीं है। यह एक और हालिया चलन है।

V596 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; RTensor.hxx 363

 template <typename Value_t, typename Container_t> inline RTensor<Value_t, Container_t> RTensor<Value_t, Container_t>::Transpose() { if (fLayout == MemoryLayout::RowMajor) { fLayout = MemoryLayout::ColumnMajor; } else if (fLayout == MemoryLayout::ColumnMajor) { fLayout = MemoryLayout::RowMajor; } else { std::runtime_error("Memory layout is not known."); } .... } 

समस्या यह है कि प्रोग्रामर ने गलती से थ्रो कीवर्ड को छोड़ दिया, इस प्रकार त्रुटि स्थिति के मामले में अपवाद को फेंकने से रोक दिया।

इस प्रकार की केवल दो चेतावनियाँ थीं। यहाँ दूसरा है:

• V596 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: रनटाइम_रोर (FOO) फेंकें; वन। XXX १३ 137

V609 को शून्य से विभाजित करें। डेनोमिनेटर रेंज [0..100]। TGHtmlImage.cxx 340

 const char *TGHtml::GetPctWidth(TGHtmlElement *p, char *opt, char *ret) { int n, m, val; .... if (n < 0 || n > 100) return z; if (opt[0] == 'h') { val = fCanvas->GetHeight() * 100; } else { val = fCanvas->GetWidth() * 100; } if (!fInTd) { snprintf(ret, 15, "%d", val / n); // <= } else { .... } .... } 

यह एक पहले चर्चा किए गए उदाहरण से निपटने वाले सरणी के समान है। N वैरिएबल 0 से 100 तक की सीमा तक सीमित है। लेकिन फिर भी एक ब्रांच है जो n वैरिएबल द्वारा डिवीजन करता है जिसका मान 0 हो सकता है। मुझे लगता है कि n की रेंज लिमिट्स को इस प्रकार तय किया जाना चाहिए:

 if (n <= 0 || n > 100) return z; 

V646 आवेदन के तर्क का निरीक्षण करने पर विचार करें। यह संभव है कि 'और' कीवर्ड गायब है। TProofServ.cxx 729

 TProofServ::TProofServ(Int_t *argc, char **argv, FILE *flog) : TApplication("proofserv", argc, argv, 0, -1) { .... if (!logmx.IsDigit()) { if (logmx.EndsWith("K")) { xf = 1024; logmx.Remove(TString::kTrailing, 'K'); } else if (logmx.EndsWith("M")) { xf = 1024*1024; logmx.Remove(TString::kTrailing, 'M'); } if (logmx.EndsWith("G")) { xf = 1024*1024*1024; logmx.Remove(TString::kTrailing, 'G'); } } .... } 

यदि अनुपलब्ध किसी अन्य कीवर्ड के साथ स्टेटमेंट में विश्लेषक अजीब रूप से स्वरूपित रिपोर्ट करता है। जिस तरह से यह कोड बताता है कि इसे ठीक करने की आवश्यकता है।

इस प्रकार की कुछ और चेतावनियाँ:

• V646 आवेदन के तर्क का निरीक्षण करने पर विचार करें। यह संभव है कि 'और' कीवर्ड गायब है। TFormula_v5.cxx 3702
• V646 आवेदन के तर्क का निरीक्षण करने पर विचार करें। यह संभव है कि 'और' कीवर्ड गायब है। RooAbsCategory.cxx 604

V663 अनंत लूप संभव है। लूप से टूटने के लिए 'Cin.eof ()' स्थिति अपर्याप्त है। सशर्त अभिव्यक्ति के लिए 'cin.fail ()' फ़ंक्शन कॉल जोड़ने पर विचार करें। MethodKNN.cxx 602

 void TMVA::MethodKNN::ReadWeightsFromStream(std::istream& is) { .... while (!is.eof()) { std::string line; std::getline(is, line); if (line.empty() || line.find("#") != std::string::npos) { continue; } .... } .... } 

जब std :: istream क्लास के साथ काम करते हैं, तो eof () फ़ंक्शन को कॉल करना लूप को समाप्त करने के लिए पर्याप्त नहीं है। यदि डेटा को पढ़ा नहीं जा सकता है, तो eof () फ़ंक्शन हमेशा गलत होगा, और इस कोड में कोई अन्य समाप्ति बिंदु नहीं हैं। लूप की समाप्ति की गारंटी देने के लिए, विफल () फ़ंक्शन द्वारा लौटाए गए मान की एक अतिरिक्त जांच आवश्यक है:

 while (!is.eof() && !is.fail()) { .... } 

एक विकल्प के रूप में, इसे निम्नानुसार फिर से लिखा जा सकता है:

 while (is) { .... } 

V678 किसी ऑब्जेक्ट का उपयोग अपनी स्वयं की पद्धति के तर्क के रूप में किया जाता है। 'कॉपी' फ़ंक्शन के पहले वास्तविक तर्क की जाँच करने पर विचार करें। TFormLeafInfo.cxx 2414

 TFormLeafInfoMultiVarDim::TFormLeafInfoMultiVarDim( const TFormLeafInfoMultiVarDim& orig) : TFormLeafInfo(orig) { fNsize = orig.fNsize; fSizes.Copy(fSizes); // <= fCounter2 = orig.fCounter2?orig.fCounter2->DeepCopy():0; fSumOfSizes = orig.fSumOfSizes; fDim = orig.fDim; fVirtDim = orig.fVirtDim; fPrimaryIndex = orig.fPrimaryIndex; fSecondaryIndex = orig.fSecondaryIndex; } 

आइए इस अच्छे छोटे टाइपो के साथ लेख को समाप्त करें। कॉपी फ़ंक्शन को मूल के साथ बुलाया जाना चाहिए। FSizes नहीं।

निष्कर्ष

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

वैसे, मैकओएस 10.15 कैटालिना को दूसरे दिन जारी किया गया था, जहां उन्होंने 32-बिट अनुप्रयोगों का समर्थन बंद कर दिया था। सौभाग्य से, पीवीएस-स्टूडियो विशेष रूप से बग का पता लगाने के लिए डिज़ाइन किए गए डायग्नोस्टिक्स का एक बड़ा सेट प्रदान करता है जो कार्यक्रमों के पोर्टिंग के साथ 64-बिट सिस्टम के साथ होता है। पीवीएस-स्टूडियो टीम द्वारा इस पोस्ट में और जानें।