🛌🏾 👨🏽‍🌾 🏼 2018 के लिए C ++ प्रोजेक्ट्स में शीर्ष 10 त्रुटियां 👷🏻 🔳 🖕🏾

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

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

यदि आप स्वयं त्रुटियों की तलाश में रुचि रखते हैं, तो आप हमेशा हमारे विश्लेषक को डाउनलोड और आज़मा सकते हैं। हम छात्रों और उत्साही प्रोग्रामर के लिए विश्लेषक का एक नि: शुल्क संस्करण प्रदान करते हैं, ओपन-सोर्स परियोजनाओं के डेवलपर्स के लिए एक मुफ्त लाइसेंस , साथ ही सभी-सभी के लिए एक परीक्षण संस्करण । कौन जानता है, शायद अगले साल तक आप अपना शीर्ष 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: मैक्रो कैसे छिपा है

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

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

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

यह पता लगाने के लिए कि मामला क्या था, शिवतोस्लाव ने गहरी खुदाई की। उन्होंने मैक्रो की परिभाषा को खोला, और देखा कि इसमें कई और नेस्टेड मैक्रोज़ थे, जिनमें से कुछ ने मैक्रोज़ को भी नेस्ट किया था। यह पता लगाना इतना कठिन था कि मुझे प्रीप्रोसेस की गई फ़ाइल का उपयोग करना पड़ा। लेकिन, अफसोस, इससे कोई फायदा नहीं हुआ। कोड की पिछली पंक्ति के स्थान पर, 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-Studio: 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; }

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

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

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

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

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

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

सातवाँ स्थान

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

वीडियो गेम उद्योग से पहला उदाहरण कोड का एक स्निपेट होगा जिसे हमने गोडोट गेम इंजन में खोजा था। अपनी आँखों से त्रुटि का पता लगाने के लिए आपको पसीना बहाना पड़ सकता है, लेकिन मुझे यकीन है कि हमारे परिष्कृत पाठक इसे संभाल सकते हैं:

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

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

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

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

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

ऐसा लग सकता है कि चक्र हमेशा के लिए चलेगा, लेकिन ऐसा नहीं है।

सबसे पहले, चर i का एक पूर्णांक अतिप्रवाह होगा, जो अपरिभाषित व्यवहार है। इसलिए, इस पर भरोसा करना इसके लायक नहीं है।

यदि मैं टाइप अहस्ताक्षरित इंट का था , तो काउंटर के अधिकतम संभव मूल्य तक पहुंचने के बाद, 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

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

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

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

पांचवा स्थान

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

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

 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 को नामित निरंतर कर्सर के नाम पर रखा गया है, और बिट निरंतर संचालन "और" में नामित निरंतर कर्सर शामिल है । ये पूरी तरह से अलग हैं, क्योंकि पहला लोअरकेस अक्षर से शुरू होता है, और दूसरा कैपिटल लेटर के साथ।

कोड सफलतापूर्वक संकलित करता है, क्योंकि 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; } .... }

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

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

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

नतीजतन, कलाई की एक झिलमिलाहट के साथ, एक कामकाजी कार्यक्रम एक गैर-काम करने वाले व्यक्ति में बदल जाता है (नहीं, सुरुचिपूर्ण शॉर्ट्स नहीं)! ऊपर दिए गए लिंक पर स्रोत लेख में इस त्रुटि को कैसे पुन: पेश किया जा सकता है, पर विवरण, लेकिन अभी के लिए मैं एक स्पष्ट परिणाम दूंगा:

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

अब हमारे विजेताओं से निपटने का समय है: हम फाइनल में जा रहे हैं!

तीसरा स्थान

स्रोत: NCBI जीनोम कार्यक्षेत्र: लुप्तप्राय अनुसंधान

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

 /** * 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 () फ़ंक्शन का उपयोग करें। यह न केवल संस्मरण () से अधिक सुरक्षित है, बल्कि संकलक द्वारा "अनदेखा" भी नहीं किया जा सकता है।

दूसरा स्थान

स्रोत: कैसे पीवीएस-स्टूडियो साढ़े तीन प्रोग्रामर की तुलना में अधिक चौकस रहा

इस शीर्ष का रजत पदक हमारे एक ग्राहक ने हमें भेजा था। उन्हें यकीन था कि विश्लेषक ने गलत चेतावनी दी थी।

यूजीन ने पत्र प्राप्त किया, इसे संक्षेप में स्कैन किया और इसे सियावेटोस्लाव को भेज दिया। 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))

यदि यह स्थिति पूरी होती है, तो चर का मान अंतराल में निहित है [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

हमारे रूसी भाषी पाठकों के लिए, मैंने लगभग मुफ्त अनुवाद किया:

 //    ,    , //    ,       //      //      //     //     ,      // - "Gepetto", Belly, _Star_ //  ,   , //    C  C++     // ================== TerrainData terrain_info; //    ... // ======================= //    ,     , //         //    ,          //      ,      ... - X //       , //         //   ,     //   ,

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

निष्कर्ष

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

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

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

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

इस पर, वर्ष 2018 के लिए हमारी शीर्ष 10 सी ++ त्रुटियां समाप्त हो गईं। आपको कौन सी जगहें सबसे ज्यादा पसंद आईं और क्यों? क्या आप 2018 में दिलचस्प उदाहरणों के साथ आए? हमें टिप्पणियों में इसके बारे में बताएं!

अगली बार तक!

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

2018 के लिए C ++ प्रोजेक्ट्स में शीर्ष 10 त्रुटियां