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

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

नहीं। 10. हम किस ऑपरेटिंग सिस्टम पर चल रहे हैं?

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

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

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

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

नहीं। 9. सबसे पहले कौन?

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_intrinsiccallassigned गैर-अशक्त हैं, इसलिए स्थिति हर समय सही हो जाएगी, जिसका अर्थ है कि दूसरी शाखा का शरीर अनुपयोगी कोड है।

इस बग का वर्णन " Huawei द्वारा आर्क कंपाइलर हाल ही में निर्मित ओपन-सोर्स की जाँच " में किया गया था।

नहीं। 8. खतरनाक बिटवाइज ऑपरेशन

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

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

यदि आप स्निपेट को ध्यान से पढ़ रहे थे (और आप थे, तो आप नहीं थे?), आपने देखा होगा कि यह प्रोजेक्ट रूट से आया है। हां, हमने इसे भी चेक किया: " ROOT कोड का विश्लेषण, वैज्ञानिक डेटा विश्लेषण फ्रेमवर्क ।"

नहीं। 7. चर को मिलाया

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

यह बग एलएलवीएम में पाया गया था। हमारे पास इस परियोजना को हर बार जांचने की परंपरा है। इस साल हमने इसे एक बार और चेक किया।

नहीं। 6. 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 सरणी के अंत में स्थित हैं क्योंकि वे findLinearSearch () विधि द्वारा पाई गई वस्तु स्थिति रखते हैं । लेकिन वास्तव में, यह सशर्त अभिव्यक्ति जाँचती है कि f0 f1 के बराबर है और यदि m_fractureBodies.size () अभिव्यक्ति f0 == f1 के परिणाम के बराबर है। यही है, यहां तीसरे ऑपरेंड को 0 या 1 के खिलाफ जांचा जाता है।

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

नहीं। 5. लाइन के अंत में क्या है?

यह एक आसान है यदि आप एक मुश्किल विस्तार से जानते हैं।

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 में बदल जाएगा, जिससे स्थिति सही हो जाएगी।

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

नहीं। 4. जादू निरंतर पाई

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 द्वारा दर्शाया जाता है।

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

एक छोटा सा मोड़

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

अब, देखते हैं कि हमारे टॉप 3 में क्या है।

नहीं। 3. एक मायावी अपवाद

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 :: अपवाद वर्ग से व्युत्पन्न वर्ग का पता लगाया है (जो कि अन्यथा निर्दिष्ट नहीं होने पर डिफ़ॉल्ट रूप से उपयोग किया जाता है)। इस कोड के साथ समस्या यह है कि जेनेरिक एसटीडी को पकड़ने का प्रयास :: अपवाद के कारण प्रोग्राम को CalcException प्रकार का एक अपवाद छूट जाएगा । यह व्यवहार इस तथ्य से उपजा है कि निजी उत्तराधिकार में निहित प्रकार के रूपांतरण की मनाही है।

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

नहीं। 2. अनछुए 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-code टुकड़े हैं, इसलिए लेखकों को इसे संशोधित करने की आवश्यकता है।

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

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

नहीं। 1. मायावी मानक कार्य

यहां बग को पहले रखा गया है। यह एक प्रभावशाली अजीब बग है, जो कोड समीक्षा के माध्यम से इसे बनाने में कामयाब रहा।

इसे स्वयं खोजने का प्रयास करें:

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

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

आप यह तर्क दे सकते हैं कि यह मैक्रो #define सच के समान है और कोड की तरह यह कभी भी कोड की समीक्षा के माध्यम से नहीं बनेगा। लेकिन इस विशेष स्निपेट ने - और खोज किए जाने के इंतजार में भंडार में बैठे थे।

इस बग पर अधिक विस्तृत टिप्पणी के लिए, " Wanna Play a Detective? Find the Bug in a Function from Midnight Commander " लेख देखें।

निष्कर्ष

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

बस अगर आपने पहले हमारे लेख नहीं पढ़े हैं, तो ये सभी बग हमारे पीवीएस-स्टूडियो स्टैटिक एनालाइज़र का उपयोग करते हुए पाए गए, जिनका आप अपने स्वयं के प्रोजेक्ट पर डाउनलोड करने और प्रयास करने के लिए स्वागत करते हैं। यह C, C ++, C #, और Java में लिखे प्रोग्राम में बग्स का पता लगाता है।

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