🤹🏼 🛢️ 👎🏼 2018 में C ++ परियोजनाओं के शीर्ष 10 कीड़े 🔩 👨🏽‍⚕️ 🚵🏻

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

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

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

नोट: मैं आपको खुद को जांचने के लिए आमंत्रित करता हूं और इससे पहले कि आप विश्लेषक चेतावनी को देखें, अपने आप को दोषों को प्रकट करने का प्रयास करें। आप कितनी त्रुटियां खोजने में सक्षम होंगे?

दसवाँ स्थान

स्रोत: इनटू स्पेस अगेन: यूनिकॉर्न विजिटेड स्टेलारियम

स्टेलेरियम नामक आभासी तारामंडल की जाँच करते समय इस त्रुटि का पता चला था।

उपरोक्त कोड टुकड़ा, हालांकि छोटा है, एक बहुत मुश्किल त्रुटि से भरा है:

Plane::Plane(Vec3f &v1, Vec3f &v2, Vec3f &v3) : distance(0.0f), sDistance(0.0f) { Plane(v1, v2, v3, SPolygon::CCW); }

मिल गया?

PVS-Studio चेतावनी : V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> प्लेन :: प्लेन (....)' का उपयोग किया जाना चाहिए। विमान। 29 29

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

लेखक को एक नेस्टेड कंस्ट्रक्टर कॉल के बजाय, C ++ 11 में पेश किए गए प्रतिनिधि प्रतिनिधि का उपयोग करना चाहिए था। उदाहरण के लिए, वह इस तरह लिख सकता था:

 Plane::Plane(Vec3f& v1, Vec3f& v2, Vec3f& v3) : Plane(v1, v2, v3, SPolygon::CCW) { distance = 0.0f; sDistance = 0.0f; }

इस तरह, सभी आवश्यक क्षेत्रों को सही ढंग से आरंभ किया गया होगा। क्या यह अद्भुत नहीं है?

नौवाँ स्थान

स्रोत: पर्ल 5: मैक्रोज़ में त्रुटियों को कैसे छिपाएं

एक बहुत ही उल्लेखनीय मैक्रो अपनी सुंदरता में नौवें स्थान पर खड़ा है।

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

 PP(pp_match) { .... MgBYTEPOS_set(mg, TARG, truebase, RXp_OFFS(prog)[0].end); .... }

यह पता लगाने के लिए कि क्या गलत था, Svyatoslav ने गहरा खोदा। उन्होंने मैक्रो की परिभाषा को खोला और देखा कि इसमें कई नेस्टेड मैक्रोज़ थे, जिनमें से कुछ ने मैक्रोज़ को भी नेस्टेड किया था। यह समझ से बाहर करना मुश्किल था, इसलिए उसे एक प्रीप्रोसेस की गई फ़ाइल का उपयोग करना पड़ा। अफसोस की बात है, यह मदद नहीं की। कोड की पिछली पंक्ति में यह पाया गया है कि Svyatoslav:

 (((targ)->sv_flags & 0x00000400) && (!((targ)->sv_flags & 0x00200000) || S_sv_only_taint_gmagic(targ)) ? (mg)->mg_len = ((prog->offs)[0].end), (mg)->mg_flags |= 0x40 : ((mg)->mg_len = (((targ)->sv_flags & 0x20000000) && !__builtin_expect(((((PL_curcop)->cop_hints + 0) & 0x00000008) ? (_Bool)1 :(_Bool)0),(0))) ? (ssize_t)Perl_utf8_length( (U8 *)(truebase), (U8 *)(truebase)+((prog->offs)[0].end)) : (ssize_t)((prog->offs)[0].end), (mg)->mg_flags &= ~0x40));

PVS- स्टूडियो चेतावनी : V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की 'और&' ऑपरेटर की तुलना में कम प्राथमिकता है। pp_hot.c 3036

मुझे लगता है, इस तरह की त्रुटि को नोटिस करना चुनौतीपूर्ण होगा। हम इस कोड पर लंबे समय से निवास कर रहे हैं, लेकिन स्पष्ट रूप से कहें तो हमें इसमें कोई त्रुटि नहीं मिली है। वैसे भी, यह खराब पठनीय कोड का काफी मनोरंजक उदाहरण है।

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

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

आठवाँ स्थान

स्रोत: क्रोमियम: अन्य त्रुटियां

अगला उदाहरण क्रोमियम परियोजना के विश्लेषण पर लेखों की श्रृंखला से लिया गया था। त्रुटि WebRTC लाइब्रेरी में छिपी हुई थी।

 std::vector<SdpVideoFormat> StereoDecoderFactory::GetSupportedFormats() const { std::vector<SdpVideoFormat> formats = ....; for (const auto& format : formats) { if (cricket::CodecNamesEq(....)) { .... formats.push_back(stereo_format); } } return formats; }

पीवीएस-स्टूडियो चेतावनी: container फॉर्मेट्स ’कंटेनर के लिए V789 CWE-672 Iterators, लूप के लिए रेंज-आधारित में उपयोग किए जाते हैं, जो 'पुश_बैक' फ़ंक्शन के कॉल पर अमान्य हो जाते हैं। stereocodecfactory.cc 89

त्रुटि यह है कि वेक्टर का आकार लूप के लिए रेंज-आधारित के भीतर बदलता रहता है। रेंज-आधारित लूप पुनरावृत्तियों पर आधारित होते हैं, यही कारण है कि इस तरह के लूप के अंदर कंटेनर आकार को बदलने से इन पुनरावृत्तियों को अमान्य किया जा सकता है।

यह त्रुटि बनी रहती है, यदि लूप पुनरावृत्तियों के स्पष्ट उपयोग के साथ फिर से लिखना। स्पष्टता के लिए, मैं निम्नलिखित कोड का हवाला दे सकता हूं:

 for (auto format = begin(formats), __end = end(formats); format != __end; ++format) { if (cricket::CodecNamesEq(....)) { .... formats.push_back(stereo_format); } }

उदाहरण के लिए, पुश_बैक विधि का उपयोग करते समय, एक वेक्टर पुनः प्राप्ति हो सकती है - इस तरह, पुनरावृत्तियाँ एक अमान्य मेमोरी स्थान को संबोधित करेंगी।

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

सातवाँ स्थान

स्रोत: गोडोट: स्टेटिक एनालिसिस के नियमित उपयोग पर

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

 void AnimationNodeBlendSpace1D::add_blend_point( const Ref<AnimationRootNode> &p_node, float p_position, int p_at_index) { ERR_FAIL_COND(blend_points_used >= MAX_BLEND_POINTS); ERR_FAIL_COND(p_node.is_null()); ERR_FAIL_COND(p_at_index < -1 || p_at_index > blend_points_used); if (p_at_index == -1 || p_at_index == blend_points_used) { p_at_index = blend_points_used; } else { for (int i = blend_points_used - 1; i > p_at_index; i++) { blend_points[i] = blend_points[i - 1]; } } .... }

पीवीएस-स्टूडियो चेतावनी: V621 CWE-835 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। यह संभव है कि लूप को गलत तरीके से निष्पादित किया जाएगा या बिल्कुल भी निष्पादित नहीं किया जाएगा। एनीमेशन_ब्लेंड_स्पेस_1 डी। सी। पी। 113

चलो लूप की स्थिति पर करीब से नजर डालें। काउंटर वैरिएबल का आरंभ मूल्य मिश्रण_ पॉइंट्स_यूज़ -1 द्वारा किया जाता है। इसके अलावा, दो पिछले चेक ( ERR_FAIL_COND और अगर में ) को देखते हुए, यह स्पष्ट हो जाता है, कि मिश्रण_ पॉइंट_यूस्ड लूप निष्पादन के क्षण तक, मिश्रण_ पॉइंट्स_यूएस हमेशा p_at_index से अधिक होगा। इस प्रकार, या तो लूप की स्थिति हमेशा सही होती है या लूप निष्पादित नहीं होता है।

अगर ब्लेंड_ पॉइंट्स_ड्यूस - 1 == p_at_index , तो लूप निष्पादित नहीं करता है।

अन्य सभी मामलों में चेक i> p_at_index हमेशा सही रहेगा, क्योंकि मैं प्रत्येक लूप पुनरावृत्ति पर काउंटर जाता है।

ऐसा लगता है कि लूप शाश्वत है, लेकिन ऐसा नहीं है।

सबसे पहले, आई वेरिएबल (जो अपरिभाषित व्यवहार है) का एक पूर्णांक ओवरफ़्लो होगा। इसका मतलब है, हमें इस पर भरोसा नहीं करना चाहिए।

यदि मैं int अहस्ताक्षरित था, तो काउंटर के सबसे बड़े संभावित मूल्य तक पहुंचने के बाद, ऑपरेटर i ++ इसे 0 में बदल देगा। इस तरह के व्यवहार को मानक द्वारा परिभाषित किया जाता है और इसे "अनसाइनड रैपिंग" कहा जाता है। हालांकि, आपको यह पता होना चाहिए कि इस तरह के तंत्र का उपयोग भी एक अच्छा विचार नहीं है ।

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

मैं आपको ऐसी ही त्रुटियों से बचने के लिए कुछ सिफारिशें दे सकता हूं:

सरल और समझने योग्य कोड लिखें
अधिक अच्छी तरह से कोड की समीक्षा करें और नए लिखित कोड के लिए अधिक परीक्षण लिखें
स्थैतिक विश्लेषक का उपयोग करें)

छठा स्थान

स्रोत: अमेजन लम्बरबार्ड: ए स्क्रीम ऑफ एंगुइश

यहाँ gamedev उद्योग से एक और उदाहरण दिया गया है, जिसका स्रोत अमेज़न लम्बरबार्ड के AAA- इंजन से है।

 void TranslateVariableNameByOperandType(....) { // Igor: yet another Qualcomm's special case // GLSL compiler thinks that -2147483648 is // an integer overflow which is not if (*((int*)(&psOperand->afImmediates[0])) == 2147483648) { bformata(glsl, "-2147483647-1"); } else { // Igor: this is expected to fix // paranoid compiler checks such as Qualcomm's if (*((unsigned int*)(&psOperand->afImmediates[0])) >= 2147483648) { bformata(glsl, "%d", *((int*)(&psOperand->afImmediates[0]))); } else { bformata(glsl, "%d", *((int*)(&psOperand->afImmediates[0]))); } } bcatcstr(glsl, ")"); .... }

PVS-Studio चेतावनी : V523 '' 'कथन' और 'कथन के बराबर है। toglsloperand.c 700

Amazon Lumberyard को एक क्रॉस-प्लेटफॉर्म इंजन के रूप में विकसित किया गया है। इस कारण से, डेवलपर अधिक से अधिक संकलक का समर्थन करने का प्रयास करते हैं। जैसा कि हम टिप्पणियों से देख सकते हैं, एक प्रोग्रामर इगोर क्वालकॉम कंपाइलर के खिलाफ आया था।

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

मुझे यह भी नहीं पता कि यहाँ क्या सलाह है। तो मैं बस अमेज़न लंबरगार्ड डेवलपर्स को त्रुटियों को ठीक करने के लिए शुभकामनाएं देता हूं और डेवलपर इगोर के लिए शुभकामनाएं!

पांचवा स्थान

स्रोत: एक बार फिर, पीवीएस-स्टूडियो विश्लेषक एक व्यक्ति की तुलना में अधिक चौकस साबित हुए हैं

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

 QWindowsCursor::CursorState QWindowsCursor::cursorState() { enum { cursorShowing = 0x1, cursorSuppressed = 0x2 }; CURSORINFO cursorInfo; cursorInfo.cbSize = sizeof(CURSORINFO); if (GetCursorInfo(&cursorInfo)) { if (cursorInfo.flags & CursorShowing) // <= V616 .... }

PVS-Studio चेतावनी: V616 CWE-480 'CursorShowing' का नाम 0 के मान के साथ स्थिर है जिसका उपयोग बिटवाइज़ ऑपरेशन में किया जाता है। qwindowscursor.cpp 669

जिसका अर्थ है, पीवीएस-स्टूडियो उस स्थान पर शिकायत कर रहा था, जिसमें स्पष्ट रूप से कोई त्रुटि नहीं थी! यह CursorShowing निरंतर 0 के लिए असंभव है, क्योंकि इसके ऊपर सिर्फ कुछ पंक्तियाँ 1 द्वारा आरंभीकृत की गई हैं।

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

केवल एक विस्तृत विश्लेषण से पता चला है कि पीवीएस-स्टूडियो फिर से एक व्यक्ति की तुलना में अधिक सावधान हो गया। 0x1 मान को एक नामित स्थिरांक को सौंपा जाता है जिसे कर्सरशूटिंग कहा जाता है जबकि CursorShowing एक बिटवाइज़ और "ऑपरेशन" में भाग लेता है। ये दो बिल्कुल अलग स्थिरांक हैं, पहला लोअरकेस अक्षर से शुरू होता है, दूसरा - एक पूंजी के साथ।

कोड सफलतापूर्वक संकलित करता है, क्योंकि वर्ग QWindowsCursor में वास्तव में इस नाम के साथ एक स्थिरांक है। इसकी परिभाषा यहाँ दी गई है:

 class QWindowsCursor : public QPlatformCursor { public: enum CursorState { CursorShowing, CursorHidden, CursorSuppressed }; .... }

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

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

चौथा स्थान

स्रोत: इनपुट डेटा को हैंडल करते समय अपने आप को पैर में गोली मार लें

हम शीर्ष तीन फाइनलिस्ट के करीब हो रहे हैं और लाइन में अगली फ्रीस्विच परियोजना से त्रुटि है।

 static const char *basic_gets(int *cnt) { .... int c = getchar(); if (c < 0) { if (fgets(command_buf, sizeof(command_buf) - 1, stdin) != command_buf) { break; } command_buf[strlen(command_buf)-1] = '\0'; /* remove endline */ break; } .... }

पीवीएस-स्टूडियो चेतावनी: V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग इंडेक्स में किया जाता है: 'स्ट्रलेन (कमांड_ब्यूफ)'।

विश्लेषक आपको चेतावनी देता है कि कुछ अनियंत्रित डेटा का उपयोग अभिव्यक्ति strlen (कमांड_ब्यूफ) - 1 में किया जाता है । वास्तव में: यदि कमांड भाषा सी भाषा के लिहाज से एक खाली स्ट्रिंग है (एकमात्र चरित्र - '\ 0'), तो स्ट्रलेन (कमांड_ब्यूफ) 0 पर वापस आ जाएगी। ऐसे मामले में, command_buf [-1] एक्सेस किया जाएगा, जो अपरिभाषित व्यवहार है। यह बुरा है!

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

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

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

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

तीसरा स्थान

स्रोत: NCBI जीनोम कार्यक्षेत्र: खतरे के तहत वैज्ञानिक अनुसंधान

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

 /** * Crypt a given password using schema required for NTLMv1 authentication * @param passwd clear text domain password * @param challenge challenge data given by server * @param flags NTLM flags from server side * @param answer buffer where to store crypted password */ void tds_answer_challenge(....) { .... if (ntlm_v == 1) { .... /* with security is best be pedantic */ memset(hash, 0, sizeof(hash)); memset(passwd_buf, 0, sizeof(passwd_buf)); ... } else { .... } }

पीवीएस-स्टूडियो चेतावनी:

V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'हैश' बफर को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। चुनौती। 365
V597 कंपाइलर 'मेमसेट' फंक्शन कॉल को डिलीट कर सकता है, जो 'passwd_buf' बफर को फ्लश करने के लिए उपयोग किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। चुनौती। ४६६

क्या आपको एक बग मिला? यदि हाँ, तो आप अटाबॉय हैं! .. या आनुवंशिक रूप से संशोधित अतिमानवीय।

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

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

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

आपको memset_s () फ़ंक्शन का उपयोग करना चाहिए, ताकि मेमोरी डीलक्लेशन सुरक्षित था। फ़ंक्शन दोनों ही मेमरी से सुरक्षित है () और एक कंपाइलर द्वारा अनदेखा नहीं किया जा सकता है।

दूसरा स्थान

स्रोत: कैसे PVS-Studio तीन और एक आधे प्रोग्रामर की तुलना में अधिक चौकस साबित हुआ

हमारे ग्राहकों में से एक ने हमें एक रजत पदक दिलाया। उन्हें यकीन था कि विश्लेषक ने कुछ झूठी सकारात्मक बातें जारी की हैं।

इवगेनी को ईमेल मिला, उसी के माध्यम से देखा और सियावेटोस्लाव को भेजा। Svyatoslav ग्राहक के द्वारा भेजे गए कोड के टुकड़े पर एक करीबी नज़र रखता था, और उसने सोचा: "यह कैसे संभव है कि विश्लेषक ने इस तरह की गड़बड़ी की है?"। इसलिए वह एंड्री के पास सलाह के लिए गया। उन्होंने उस स्थान को भी जांचा और निर्धारित किया: वास्तव में, विश्लेषक ने झूठी सकारात्मकता उत्पन्न की।

तो यह जाता है, कि फिक्सिंग की जरूरत है। हमारे बग ट्रैकर में कार्य बनाने के लिए केवल सियावेटोस्लाव ने सिंथेटिक उदाहरण बनाने शुरू किए, तो उन्हें वही मिला जो गलत था।

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

क्या आपको ऐसा चालाक बग मिलेगा? सतर्कता और सावधानी पर खुद को परखें।

पीवीएस-स्टूडियो चेतावनी:

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: (ch> = 0x0FF21)। decodew.cpp 525
V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: (ch <= 0x0FF3A)। decodew.cpp 525
V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: (ch> = 0x0FF41)। decodew.cpp 525
V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: (ch <= 0x0FF5A)। decodew.cpp 525

यदि आपने ऐसा किया है - आप के लिए यश!

त्रुटि इस तथ्य में निहित है कि तार्किक निषेध ऑपरेटर (!) पूरी स्थिति पर लागू नहीं होता है, लेकिन केवल इसका पहला उप-अभिव्यक्ति:

 !((ch >= 0x0FF10) && (ch <= 0x0FF19))

यदि यह स्थिति सही है, तो ch चर मान [0x0FF10 ... 0x0FF19] श्रेणी में है। इस प्रकार, चार और तुलनाएं पहले से ही निरर्थक हैं: वे हमेशा सही या गलत होंगे।

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

 const bool isLetterOrDigit = (ch >= 0x0FF10 && ch <= 0x0FF19) // 0..9 || (ch >= 0x0FF21 && ch <= 0x0FF3A) // A..Z || (ch >= 0x0FF41 && ch <= 0x0FF5A); // a..z if (!isLetterOrDigit)

इस प्रकार, कम कोष्ठक होंगे और दूसरी ओर - आप कभी-कभार एक त्रुटि को नोटिस करेंगे।

यहाँ शीर्ष पर चेरी आता है - चलो पहले स्थान पर चलते हैं!

पहला स्थान

स्रोत: शॉक्ड सिस्टम: लेजेंडरी सिस्टम शॉक के स्रोत कोड में दिलचस्प त्रुटियां

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

लेकिन पहले मुझे कबूल करना होगा। अब मैं आपको जो दिखाने जा रहा हूं, उसमें कोई त्रुटि नहीं है। असल में, यह कोड का एक टुकड़ा भी नहीं है, लेकिन मैं सिर्फ इसे आपके साथ साझा करने में मदद नहीं कर सकता!

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

 // I'll give you fish, I'll give you candy, // I'll give you, everything I have in my hand // that kid from the wrong side came over my house again, // decapitated all my dolls // and if you bore me, you lose your soul to me // - "Gepetto", Belly, _Star_ // And here, ladies and gentlemen, // is a celebration of C and C++ and their untamed passion... // ================== TerrainData terrain_info; // Now the actual stuff... // ======================= // this is all outrageously horrible, as we dont know what // we really need to deal with here // And if you thought the hack for papers was bad, // wait until you see the one for datas... - X // Returns whether or not in the humble opinion of the // sound system, the sample should be politely obliterated // out of existence // it's a wonderful world, with a lot of strange men // who are standing around, and they all wearing towels

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

निष्कर्ष

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

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

उदाहरण के लिए, हमने कई नए संकलकों का समर्थन जोड़ा है और नैदानिक नियमों की सूची का विस्तार किया है। इसके अलावा हमने MISRA C और MISRA C ++ मानकों का प्रारंभिक समर्थन लागू किया है । सबसे महत्वपूर्ण और समय लेने वाली नई सुविधा एक नई भाषा का समर्थन थी। हाँ, अब हम जावा में कोड का विश्लेषण कर सकते हैं! और क्या अधिक है, हमारे पास एक नवीनीकृत आइकन है :)

मैं अपने पाठकों को भी धन्यवाद देना चाहता हूं। हमारे लेख पढ़ने और हमें लिखने के लिए धन्यवाद! आप बहुत संवेदनशील हैं और आप हमारे लिए बहुत महत्वपूर्ण हैं!

2018 की हमारी शीर्ष 10 सी ++ त्रुटियां समाप्त हो गई हैं। आपको कौन-कौन से टुकड़े पसंद आए और क्यों? क्या आप 2018 में कुछ दिलचस्प उदाहरणों के साथ आए?

सभी बेहतरीन, अगली बार मिलते हैं!

2018 में C ++ परियोजनाओं के शीर्ष 10 कीड़े