2019 के लिए C ++ प्रोजेक्ट्स में शीर्ष 10 कीड़े

एक और साल खत्म होने वाला है, इसलिए कॉफी बनाने और बीते साल की बग रिपोर्ट दोबारा पढ़ने का समय आ गया है। बेशक, इसमें बहुत समय लगेगा, इसलिए यह लेख लिखा गया था। मेरा सुझाव है कि परियोजनाओं के सबसे दिलचस्प अंधेरे स्थानों पर एक नज़र डालें जो हमें 2019 में सी और सी ++ में लिखी गई परियोजनाओं में मिले थे।

दसवाँ स्थान: "हमारा OS क्या है?"

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

#if !defined(__UNICODE_STRING_DEFINED) && defined(__MINGW32_) #define __UNICODE_STRING_DEFINED #endif 

यहां, मैक्रो नाम में एक टाइपो बनाया गया था __MINGW32 _ (MINGW32 घोषणा __MINGW32__)। परियोजना के अन्य स्थानों में, सत्यापन सही ढंग से लिखा गया है:

यह, संयोग से, लेख " CMake: केस: जब परियोजना अपने कोड की गुणवत्ता के लिए अक्षम्य है " में न केवल पहली त्रुटि थी, लेकिन सामान्य रूप से V1040 निदान द्वारा वास्तविक ओपन प्रोजेक्ट (19 अगस्त, 2019) में पहली वास्तविक त्रुटि मिली।

नौवां स्थान: "सबसे पहले कौन है?"

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '==' ऑपरेटर की तुलना में कम प्राथमिकता है। mir_parser.cpp 884

 enum Opcode : uint8 { kOpUndef, .... OP_intrinsiccall, OP_intrinsiccallassigned, .... kOpLast, }; bool MIRParser::ParseStmtIntrinsiccall(StmtNodePtr &stmt, bool isAssigned) { Opcode o = !isAssigned ? (....) : (....); auto *intrnCallNode = mod.CurFuncCodeMemPool()->New<IntrinsiccallNode>(....); lexer.NextToken(); if (o == !isAssigned ? OP_intrinsiccall : OP_intrinsiccallassigned) { intrnCallNode->SetIntrinsic(GetIntrinsicID(lexer.GetTokenKind())); } else { intrnCallNode->SetIntrinsic(static_cast<MIRIntrinsicID>(....)); } .... } 

हम इस कोड के निम्नलिखित भाग में रुचि रखते हैं:

 if (o == !isAssigned ? OP_intrinsiccall : OP_intrinsiccallassigned) { .... } 

ऑपरेटर '==' में टर्नेरी ऑपरेटर (:)! से अधिक प्राथमिकता है। इस वजह से, सशर्त अभिव्यक्ति का सही मूल्यांकन नहीं किया जाता है। लिखित कोड निम्नलिखित के बराबर है:

 if ((o == !isAssigned) ? OP_intrinsiccall : OP_intrinsiccallassigned) { .... } 

और इस तथ्य को ध्यान में रखते हुए कि स्थिरांक OP_intrinsiccall और OP_intrinsiccallassign के पास गैर-मान है, यह स्थिति हमेशा सही मान देती है। दूसरी शाखा का शरीर अनुपयोगी कोड है।

यह त्रुटि लेख " हाल ही में हुआवेई द्वारा खोले गए सन्दूक कंपाइलर कोड की जाँच " से हमारे शीर्ष पर आई।

आठवाँ स्थान: "बिटवाइज़ ऑपरेशन्स का ख़तरा"

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); 

क्योंकि चूंकि फ़ंक्शन टाइप इंट का परिणाम देता है, न कि बूल के साथ , ऑपरेशन '& =', यहां तक ​​कि संख्याओं के साथ मान गलत देगा । सब के बाद, कम से कम महत्वपूर्ण बिट संख्या हमेशा शून्य होगी। इसलिए, इस तरह की एक अस्पष्ट त्रुटि वैध तर्कों के लिए भी SetFunctionsList फ़ंक्शन के परिणाम को खराब कर देगी ।

यदि आप उदाहरण से कोड को ध्यान से पढ़ते हैं (और आप ध्यान से पढ़ते हैं, तो ठीक है?), तो आप देख सकते हैं कि यह कोड ROOT प्रोजेक्ट से है। बेशक, हमने इसका परीक्षण किया: " रूट कोड विश्लेषण - वैज्ञानिक अनुसंधान डेटा के विश्लेषण के लिए एक रूपरेखा ।"

सातवीं जगह: "चर में भ्रम"

V1001 [CWE-563] 'मोड' वेरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। SIModeRegister.cpp 48

 struct Status { unsigned Mask; unsigned Mode; Status() : Mask(0), Mode(0){}; Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) { Mode &= Mask; }; .... }; 

फ़ंक्शन के तर्क को कक्षा के सदस्यों के समान नाम देना बहुत खतरनाक है। भ्रमित होने में बहुत आसान है। हमारे सामने सिर्फ एक ऐसा मामला है। इस अभिव्यक्ति का कोई मतलब नहीं है:

 Mode &= Mask; 

फ़ंक्शन का तर्क बदलता है। और वह यह है। इस तर्क का अब उपयोग नहीं किया जाता है। सबसे अधिक संभावना है, यह इस तरह से लिखना आवश्यक था:

 Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) { this->Mode &= Mask; }; 

और यह LLVM से एक त्रुटि है। हमारे पास इस परियोजना का विश्लेषण करने के लिए समय-समय पर एक परंपरा है। इस वर्ष हमारे पास सत्यापन पर एक लेख भी है।

छठा स्थान: "C ++ के अपने कानून हैं"

निम्नलिखित त्रुटि कोड में इस तथ्य के कारण दिखाई देती है कि C ++ नियम हमेशा गणितीय नियमों या "सामान्य ज्ञान" के साथ मेल नहीं खाते हैं। अपने लिए नोटिस जहां त्रुटि कोड के एक छोटे से स्निपेट में है?

V709 संदिग्ध तुलना में पाया गया: 'f0 == f1 == m_fractureBodies.size ()'। याद रखें कि 'a == b == c' 'a == b && b == c' के बराबर नहीं है। btFractureDynamicsWorld.cpp 483

 btAlignedObjectArray<btFractureBody*> m_fractureBodies; void btFractureDynamicsWorld::fractureCallback() { for (int i = 0; i < numManifolds; i++) { .... int f0 = m_fractureBodies.findLinearSearch(....); int f1 = m_fractureBodies.findLinearSearch(....); if (f0 == f1 == m_fractureBodies.size()) continue; .... } .... } 

ऐसा लगता है कि हालत की जाँच करता है कि f0 f1 के बराबर है और m_fractureBodies में तत्वों की संख्या के बराबर है। ऐसा लगता है कि इस तुलना की जाँच होनी चाहिए अगर f0 और f1 m_fractureBodies सरणी के अंत में हैं, क्योंकि वे खोजलीन खोज () विधि द्वारा पाई गई वस्तु की स्थिति को समाहित करते हैं। हालांकि, वास्तव में, यह अभिव्यक्ति यह देखने के लिए चेक में बदल जाती है कि क्या f0 और f1 बराबर हैं, और फिर यह देखने के लिए कि m_fractureBodies.size () f0 == f1 के परिणाम के बराबर है या नहीं। नतीजतन, यहां तीसरे ऑपरेंड की तुलना 0 या 1 के साथ की जाती है।

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

पांचवा स्थान: "पंक्ति का अंत क्या है?"

यदि आप एक सूक्ष्मता के बारे में जानते हैं तो निम्न त्रुटि का आसानी से पता लगाया जा सकता है।

V739 ईओएफ की तुलना 'चार' प्रकार के मूल्य से नहीं की जानी चाहिए। 'Ch' 'int' प्रकार का होना चाहिए। json.cpp 762

 void JsonIn::skip_separator() { signed char ch; .... if (ch == ',') { if( ate_separator ) { .... } .... } else if (ch == EOF) { .... } 

यह उन त्रुटियों में से एक है जिन्हें नोटिस करना मुश्किल हो सकता है यदि आप नहीं जानते कि ईओएफ -1 के रूप में परिभाषित किया गया है। तदनुसार, यदि आप इसे टाइप किए गए चार्ट के चर के साथ तुलना करने का प्रयास करते हैं, तो स्थिति लगभग हमेशा झूठी होती है । एकमात्र अपवाद यदि वर्ण कोड 0xFF (255) है। तुलना करते समय, ऐसा प्रतीक -1 में बदल जाएगा और स्थिति सही होगी।

इस शीर्ष में खेलों से संबंधित बहुत सारी गलतियाँ हैं: इंजन से लेकर खुले खेल तक। जैसा कि आपने अनुमान लगाया होगा कि यह स्थान भी इसी क्षेत्र से हमारे पास आया था। आप लेख में अधिक त्रुटियां देख सकते हैं " कैटेक्लीसम डार्क डेज अहेड, स्टेटिक एनालिसिस एंड बैगल्स ।"

चौथा स्थान: "नंबर पी का जादू"

V624 '3.141592538' स्थिरांक में एक गलतफहमी है। <Math.h> से M_PI निरंतर का उपयोग करने पर विचार करें। PhysicsClientC_API.cpp 4109

 B3_SHARED_API void b3ComputeProjectionMatrixFOV(float fov, ....) { float yScale = 1.0 / tan((3.141592538 / 180.0) * fov / 2); .... } 

संख्या पाई (3.141592653 ...) में एक छोटा टाइपो, फ्रैक्चर भाग में 7 वें स्थान पर "6" नंबर गायब है।

शायद दस-दसवें दशमलव स्थान में त्रुटि मूर्त परिणाम नहीं देगी, लेकिन आपको अभी भी बिना लायब्रेरी के मौजूदा लाइब्रेरी स्थिरांक का उपयोग करना चाहिए। उदाहरण के लिए, Pi के लिए, math.h हैडर से एक M_PI स्थिरांक है।

यह त्रुटि " पीवीएस-स्टूडियो ने रेड डेड रिडेम्पशन - बुलेट इंजन में देखा " लेख से है, जो पहले से ही छठे स्थान पर है। यदि आपने इसे बाद के लिए बंद नहीं किया है, तो यह अंतिम मौका है।

थोड़ा सा विषयांतर

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

और अब मैं आपके ध्यान को पहले तीन पर लाता हूं।

तीसरा स्थान: "मायावी अपवाद"

V702 क्लासेस को हमेशा std :: अपवाद (और एक जैसे) से 'पब्लिक' के रूप में लिया जाना चाहिए (कोई कीवर्ड निर्दिष्ट नहीं किया गया था, इसलिए कंपाइलर इसे 'निजी' में डिफॉल्ट करता है)। CalcManager CalcException.h 4

 class CalcException : std::exception { public: CalcException(HRESULT hr) { m_hr = hr; } HRESULT GetException() { return m_hr; } private: HRESULT m_hr; }; 

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

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

दूसरी जगह: HTML टैग्स को अनक्लोज किया गया

V735 संभवतः एक गलत HTML है। "</ Body>" समापन टैग का सामना करना पड़ा, जबकि "</ div>" टैग अपेक्षित था। book.cpp 127

 static QString makeAlgebraLogBaseConversionPage() { return BEGIN INDEX_LINK TITLE(Book::tr("Logarithmic Base Conversion")) FORMULA(y = log(x) / log(a), log<sub>a</sub>x = log(x) / log(a)) END; } 

जैसा कि अक्सर C / C ++ कोड के साथ होता है, स्रोत से कुछ भी स्पष्ट नहीं होता है, तो आइए इस खंड के लिए प्रीप्रोसेस किए गए कोड की ओर मुड़ें:

विश्लेषक ने एक अस्पष्ट <div> टैग का पता लगाया। इस फ़ाइल में html कोड के कई टुकड़े हैं और अब इसे डेवलपर्स द्वारा अतिरिक्त रूप से जांचा जाना चाहिए।

आश्चर्य है कि हम जाँच कर सकते हैं और इस तरह? जब मैंने पहली बार यह देखा, तो मैं प्रभावित हुआ। इसलिए हम html कोड का थोड़ा विश्लेषण करते हैं। सच है, केवल C ++ कोड में। :)

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

पहला स्थान: "मायावी मानक सुविधाएँ"

इसलिए हम पहले स्थान पर पहुंच गए। एक प्रभावशाली अजीब समस्या जो एक कोड समीक्षा के माध्यम से चली गई।

इसे स्वयं खोजने की कोशिश करें:

 static int EatWhitespace (FILE * InFile) /* ----------------------------------------------------------------------- ** * Scan past whitespace (see ctype(3C)) and return the first non-whitespace * character, or newline, or EOF. * * Input: InFile - Input source. * * Output: The next non-whitespace character in the input stream. * * Notes: Because the config files use a line-oriented grammar, we * explicitly exclude the newline character from the list of * whitespace characters. * - Note that both EOF (-1) and the nul character ('\0') are * considered end-of-file markers. * * ----------------------------------------------------------------------- ** */ { int c; for (c = getc (InFile); isspace (c) && ('\n' != c); c = getc (InFile)) ; return (c); } /* EatWhitespace */ 

अब देखते हैं कि विश्लेषक क्या कहता है:

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: ('\ n'! = C)। params.c 136।

अजीब है, है ना? आइए एक ही परियोजना में कुछ दिलचस्प देखें, लेकिन एक अलग फ़ाइल (charset.h) में:

 #ifdef isspace #undef isspace #endif .... #define isspace(c) ((c)==' ' || (c) == '\t') 

तो, और यह पहले से ही वास्तव में अजीब है ... यह पता चला है कि अगर चर c '\ n' के बराबर है , तो पहली नज़र में isspace (c) फ़ंक्शन में बिल्कुल हानिरहित वापस आ जाएगा और इस परीक्षण का दूसरा भाग शॉर्ट-सर्किट मूल्यांकन के कारण नहीं किया जाएगा। यदि isspace (c) निष्पादित किया जाता है, तो चर c या तो '' या 't' है, और यह स्पष्ट रूप से '\ n' के बराबर नहीं है।

बेशक, आप कह सकते हैं कि यह मैक्रो #define सच की तरह है, और इस तरह का कोड कभी भी कोड की समीक्षा नहीं करेगा। हालांकि, इस कोड ने समीक्षा पारित कर दी और परियोजना भंडार में सुरक्षित रूप से हमारा इंतजार कर रहा था।

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

निष्कर्ष

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

यदि कोई हमारे लेखों को पहली बार पढ़ता है, तो बस, मैं स्पष्ट करता हूं कि ये सभी त्रुटियां PVS-Studio स्टैटिक कोड एनालाइज़र का उपयोग करते हुए पाई गई थीं, जिन्हें हम डाउनलोड करने और प्रयास करने का सुझाव देते हैं। विश्लेषक भाषाओं में लिखे गए कार्यक्रमों के कोड में त्रुटियों का पता लगा सकता है: C, C ++, C # और Java।

तो हम अंत तक आ गए हैं! यदि आप पहले दो स्तरों से चूक गए हैं, तो मैं सुझाव देता हूं कि अवसर को न छोड़ें और उनके साथ हमारे माध्यम से जाएं: सी # और जावा ।

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद लिंक का उपयोग करें: मैक्सिम ज़िवगिंटसेव। 2019 में C ++ प्रोजेक्ट्स में शीर्ष 10 कीड़े मिले ।