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

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

नियमित रूप से विश्लेषक का उपयोग करें

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

यह ध्यान दिया जाना चाहिए कि हमने पहले ही 2015 में इस परियोजना की जांच की थी , और लेखक ने उन त्रुटियों के साथ काम किया जो हमने लिखा था। यहां आप संबंधित कमिटमेंट देख सकते हैं।

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

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

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

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

अब आइए बगों पर चलते हैं कि हमारे प्रकाशनों के पाठक कितना पसंद करते हैं।

कॉपी-पेस्ट त्रुटियां

आइए देखें कि पीवीएस-स्टूडियो रिपोर्ट का अध्ययन करते समय मैंने क्या देखा। मैं अपने पसंदीदा V501 डायग्नोस्टिक के साथ शुरू करूँगा, जो लगभग हर परियोजना में त्रुटियों को ढूंढता है जिसे हम जांचते हैं :)।

त्रुटि N १

virtual bool can_export(....) { .... if (!exists_export_template("uwp_" + platform_infix + "_debug.zip", &err) || !exists_export_template("uwp_" + platform_infix + "_debug.zip", &err)) { valid = false; r_missing_templates = true; } .... } 

PVS-Studio चेतावनी: V501 CWE-570 समान उप-अभिव्यक्तियाँ हैं! 'Exists_export_template ("uwp_" + platform_infix + "_debug.zip", और इरेट)' बाईं ओर और 'दाईं ओर' || ऑपरेटर। निर्यात

शास्त्रीय कॉपी-पेस्ट त्रुटि। फ़ंक्शन कॉल की प्रतिलिपि बनाई गई है लेकिन संपादित नहीं की गई है। संसाधित होने वाली दूसरी फ़ाइल का नाम "_release.zip" के साथ समाप्त होना चाहिए।

त्रुटियां एन 2, एन 3

 static String dump_node_code(SL::Node *p_node, int p_level) { .... if (bnode->statements[i]->type == SL::Node::TYPE_CONTROL_FLOW || bnode->statements[i]->type == SL::Node::TYPE_CONTROL_FLOW) { code += scode; //use directly } else { code += _mktab(p_level) + scode + ";\n"; } .... } 

PVS-Studio चेतावनी: V501 CWE-570 समान उप-अभिव्यक्तियाँ हैं 'bnode-> स्टेटमेंट्स [i] -> टाइप == SL :: Node :: TYPE_CONTROL_FLOW' बाईं ओर और 'दाईं ओर' || ऑपरेटर। test_shader_lang.cpp 183

 void EditorSpinSlider::_notification(int p_what) { if (p_what == MainLoop::NOTIFICATION_WM_FOCUS_OUT || p_what == MainLoop::NOTIFICATION_WM_FOCUS_OUT) { if (grabbing_spinner) { Input::get_singleton()->set_mouse_mode(Input::MOUSE_MODE_VISIBLE); grabbing_spinner = false; grabbing_spinner_attempt = false; } } .... } 

PVS-Studio चेतावनी: V501 CWE-570 समान उप-अभिव्यक्तियाँ हैं 'p_what == MainLoop :: NOTIFICATION_WM_FOCUS_OUT' बाईं और दाईं ओर '' || ऑपरेटर। Editor_spin_slider.cpp 157

मुझे लगता है कि त्रुटियां स्पष्ट रूप से दिखाई दे रही हैं और किसी भी स्पष्टीकरण की आवश्यकता नहीं है। वास्तव में वही क्लासिक कॉपी-पेस्ट, जैसा कि पहले मामले में था।

त्रुटि N4

 String SoftBody::get_configuration_warning() const { .... Transform t = get_transform(); if ((ABS(t.basis.get_axis(0).length() - 1.0) > 0.05 || ABS(t.basis.get_axis(1).length() - 1.0) > 0.05 || ABS(t.basis.get_axis(0).length() - 1.0) > 0.05)) { if (!warning.empty()) .... } 

PVS-Studio चेतावनी: V501 CWE-570 बाईं और 'दाईं ओर' के समान उप-अभिव्यक्तियाँ हैं। ऑपरेटर। soft_body.cpp 399

यहां पहली पंक्ति को दो बार कॉपी किया गया था। लेकिन समन्वय अक्ष संख्या केवल दूसरी पंक्ति में बदल दी गई थी। और वे तीसरी पंक्ति को संपादित करना भूल गए। यह " लास्ट लाइन इफेक्ट " के अलावा और कुछ नहीं है।

नोट। फिलहाल, "लास्ट लाइन इफेक्ट" के अलावा, मैंने निम्नलिखित दिलचस्प टिप्पणियां की हैं: " सी / सी ++ दुनिया में सबसे खतरनाक कार्य ", " ईविल तुलना कार्यों में रहता है "। और अब मैं एक नए लेख की घोषणा करूंगा, जिसके लेखन की योजना निकट भविष्य में करने की मेरी योजना है। काम करने का शीर्षक "0, 1, 2" है। यह दिलचस्प और शिक्षाप्रद होना चाहिए। मैं आपको मिस न करने के लिए किसी एक चैनल की सदस्यता लेने के लिए आमंत्रित करता हूं: ट्विटर , vk.com , इंस्टाग्राम , टेलीग्राम और "ओल्ड स्कूल" टॉस ।

त्रुटि N5

 void ScrollContainer::_notification(int p_what) { .... if (h_scroll->is_visible_in_tree() && h_scroll->get_parent() == this) size.y -= h_scroll->get_minimum_size().y; if (v_scroll->is_visible_in_tree() && v_scroll->get_parent() == this) size.x -= h_scroll->get_minimum_size().x; .... } 

PVS-Studio चेतावनी: V778 CWE-682 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'h_scroll' के बजाय 'v_scroll' चर का उपयोग किया जाना चाहिए। स्क्रोल_कंटेनर.कैप 249

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

कोड शायद इस तरह होना चाहिए:

 if (h_scroll->is_visible_in_tree() && h_scroll->get_parent() == this) size.y -= h_scroll->get_minimum_size().y; if (v_scroll->is_visible_in_tree() && v_scroll->get_parent() == this) size.x -= v_scroll->get_minimum_size().x; 

त्रुटि N6

एक और मामला जहां एक बड़ा पर्याप्त कोड टुकड़ा कॉपी किया गया था और असफल रूप से बदल दिया गया था। त्रुटि लाइन मेरी टिप्पणी "// <=" द्वारा चिह्नित है।

 void ShaderGLES2::bind_uniforms() { .... const Map<uint32_t, Variant>::Element *E = uniform_defaults.front(); while (E) { int idx = E->key(); int location = version->uniform_location[idx]; if (location < 0) { E = E->next(); continue; } Variant v; v = E->value(); _set_uniform_variant(location, v); E = E->next(); } const Map<uint32_t, CameraMatrix>::Element *C = uniform_cameras.front(); while (C) { int idx = E->key(); // <= int location = version->uniform_location[idx]; if (location < 0) { C = C->next(); continue; } glUniformMatrix4fv(location, 1, GL_FALSE, &(C->get().matrix[0][0])); C = C->next(); } uniforms_dirty = false; } 

PVS-Studio चेतावनी: V522 CWE-476 अशक्त सूचक 'E' की डेरेफेरिंग हो सकती है। shader_gles2.cpp 102

अप्रत्यक्ष रूप से त्रुटि का पता चला था। डेटा प्रवाह के विश्लेषण के लिए धन्यवाद , पीवीएस-स्टूडियो ने खुलासा किया कि सूचक ई डेरीफ्रेंसिंग के समय शून्य हो सकते हैं।

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

शुद्धिपत्र

त्रुटि N7

यह प्रोग्रामर के लिए मुश्किल है जो C या C ++ के अलावा अन्य भाषाओं में लिखते हैं कि कल्पना करें कि तारांकन चिह्न * के बजाय अल्पविराम लिखकर बनाया जा सकता है, और कोड संकलित किया जाएगा। हालाँकि, ऐसा है।

 LRESULT OS_Windows::WndProc(....) { .... BITMAPINFO bmi; ZeroMemory(&bmi, sizeof(BITMAPINFO)); bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth = dib_size.x; bmi.bmiHeader.biHeight = dib_size.y; bmi.bmiHeader.biPlanes = 1; bmi.bmiHeader.biBitCount = 32; bmi.bmiHeader.biCompression = BI_RGB; bmi.bmiHeader.biSizeImage = dib_size.x, dib_size.y * 4; .... } 

PVS-Studio चेतावनी: V521 CWE-480 ',' ऑपरेटर का उपयोग करने वाले ऐसे भाव खतरनाक हैं। सुनिश्चित करें कि अभिव्यक्ति सही है। os_windows.cpp 776

चर bmi.bmiHeader.biSizeImage को चर dib_size.x का मान दिया गया है। इसके बाद, अल्पविराम ऑपरेटर ',' निष्पादित किया जाता है, जिसकी प्राथमिकता ऑपरेटर '=' की तुलना में कम है। अभिव्यक्ति का परिणाम dib_size.y * 4 किसी भी तरह से उपयोग नहीं किया जाता है।

अभिव्यक्ति में अल्पविराम के बजाय गुणन ऑपरेटर '*' का उपयोग किया जाना चाहिए। सबसे पहले, इस तरह की अभिव्यक्ति का मतलब होगा। दूसरे, नीचे एक समान है, लेकिन एक ही चर को शुरू करने के लिए पहले से ही सही विकल्प है:

 bmi.bmiHeader.biSizeImage = dib_size.x * dib_size.y * 4; 

त्रुटियां एन 8, एन 9

 void Variant::set(....) { .... int idx = p_index; if (idx < 0) idx += 4; if (idx >= 0 || idx < 4) { Color *v = reinterpret_cast<Color *>(_data._mem); (*v)[idx] = p_value; valid = true; } .... } 

PVS-Studio चेतावनी: V547 CWE-571 अभिव्यक्ति 'idx> = 0 || idx <4 'हमेशा सत्य होता है। variant_op.cpp 2152

किसी भी सूचकांक को सही माना जाएगा। त्रुटि को ठीक करने के लिए, आपको प्रतिस्थापित करने की आवश्यकता है || && पर:

 if (idx >= 0 && idx < 4) { 

लापरवाही के कारण यह तार्किक त्रुटि सबसे अधिक उत्पन्न हुई, इसलिए मैं इसे टाइपोस करने के लिए इच्छुक हूं।

ठीक उसी त्रुटि को नीचे एक ही फ़ाइल में देखा जा सकता है। प्रजनन त्रुटि का दोष, जाहिरा तौर पर, कॉपी-पेस्ट है।

एकाधिक त्रुटि: V547 CWE-571 अभिव्यक्ति 'idx> = 0 || idx <4 'हमेशा सत्य होता है। variant_op.cpp 2527

त्रुटि N10

एक त्रुटि का एक उदाहरण जो एक से प्राप्त करना चाहता है: डब्ल्यूटीएफ!

 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

लूप स्टॉप स्थिति पर ध्यान दें: i> p_at_index । यह हमेशा सही होता है, क्योंकि वैरिएबल I को वेल्यू ब्लेंड_ पॉइंट्स_यूज्ड - 1 के साथ शुरू किया जाता है। इसके अलावा, दो पहले के चेक से यह इस प्रकार है कि मिश्रण_ पॉइंट्स_यूस्ड> p_at_index ।

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

हमसे पहले, मेरी राय में, एक सुंदर टाइपो है जब उन्होंने '<' के बजाय '>' लिखा था। हां, मेरे पास गलतियों की सुंदरता का एक विकृत दृष्टिकोण है :)।

सही चक्र:

 for (int i = blend_points_used - 1; i < p_at_index; i++) { 

त्रुटि N11

चक्र की स्थिति में टाइपो का एक और समान रूप से उज्ज्वल मामला।

 void AnimationNodeStateMachineEditor::_state_machine_pos_draw() { .... int idx = -1; for (int i = 0; node_rects.size(); i++) { if (node_rects[i].node_name == playback->get_current_node()) { idx = i; break; } } .... } 

पीवीएस-स्टूडियो चेतावनी: V693 CWE-835 लूप की सशर्त अभिव्यक्ति का निरीक्षण करने पर विचार करें। यह संभव है कि s X.size () ’के बजाय is i <X.size ()’ का उपयोग किया जाए। एनीमेशन_स्टैट_मचाइन_डिटर। सीपी m५२

सरणी का एक अतिप्रवाह हो सकता है, क्योंकि मैं का मूल्य अनियंत्रित रूप से बढ़ जाता है। सुरक्षित कोड:

 for (int i = 0; i < node_rects.size(); i++) { 

त्रुटि N12

 GDScriptDataType GDScriptCompiler::_gdtype_from_datatype( const GDScriptParser::DataType &p_datatype) const { .... switch (p_datatype.kind) { .... case GDScriptParser::DataType::NATIVE: { result.kind = GDScriptDataType::NATIVE; result.native_type = p_datatype.native_type; } break; case GDScriptParser::DataType::SCRIPT: { result.kind = GDScriptDataType::SCRIPT; result.script_type = p_datatype.script_type; result.native_type = result.script_type->get_instance_base_type(); } case GDScriptParser::DataType::GDSCRIPT: { result.kind = GDScriptDataType::GDSCRIPT; result.script_type = p_datatype.script_type; result.native_type = result.script_type->get_instance_base_type(); } break; .... } 

PVS-Studio चेतावनी: V796 CWE-484 यह संभव है कि स्विच स्टेटमेंट में 'ब्रेक' स्टेटमेंट गायब है। gdscript_compiler.cpp 135

गलती से ब्रेक स्टेटमेंट लिखना भूल गए। इसलिए, जब यह GDScriptParser के मामले में हो जाता है :: DataType :: SCRIPT, चर मानों को असाइन किया जाएगा, जैसे कि यह GDScriptParser :: DataType :: GDSCRIPT था ।

त्रुटि N13

निम्न त्रुटि को कॉपी-पेस्ट के रूप में वर्गीकृत किया जा सकता है। हालांकि, मुझे यकीन नहीं है कि इतनी छोटी लाइन की नकल की गई थी। इसलिए हम इसे टाइप करते समय एक सरल टाइपो पर विचार करेंगे।

 void CPUParticles::_particles_process(float p_delta) { .... if (flags[FLAG_DISABLE_Z]) { p.velocity.z = 0.0; p.velocity.z = 0.0; } .... } 

PVS-Studio चेतावनी: V519 CWE-563 'p.velocity.z' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 664, 665. cpu_particles.cpp 665

एक ही चर के दो बार असाइनमेंट। नीचे आप निम्न कोड टुकड़ा देख सकते हैं:

 if (flags[FLAG_DISABLE_Z]) { p.velocity.z = 0.0; p.transform.origin.z = 0.0; } 

सबसे अधिक संभावना है, पहले मामले के लिए इसे उसी तरह लिखा जाना चाहिए था।

त्रुटि N14

 bool AtlasTexture::is_pixel_opaque(int p_x, int p_y) const { if (atlas.is_valid()) { return atlas->is_pixel_opaque( p_x + region.position.x + margin.position.x, p_x + region.position.y + margin.position.y ); } return true; } 

PVS-Studio चेतावनी: V751 पैरामीटर 'p_y' का उपयोग फ़ंक्शन बॉडी के अंदर नहीं किया जाता है। बनावट। १० texture५

V751 निदान के विवरण से खुशबू :

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

जैसा कि आप देख सकते हैं, यह वास्तव में ऐसा है, और यह बहुत ही संदिग्ध है। चर p_x का उपयोग दो बार किया जाता है, और p_y का उपयोग नहीं किया जाता है। सबसे अधिक संभावना है, यह लिखा जाना चाहिए:

 return atlas->is_pixel_opaque( p_x + region.position.x + margin.position.x, p_y + region.position.y + margin.position.y ); 

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

त्रुटि N15

 bool SpriteFramesEditor::can_drop_data_fw(....) const { .... Vector<String> files = d["files"]; if (files.size() == 0) return false; for (int i = 0; i < files.size(); i++) { String file = files[0]; String ftype = EditorFileSystem::get_singleton()->get_file_type(file); if (!ClassDB::is_parent_class(ftype, "Texture")) { return false; } } .... } 

PVS-Studio चेतावनी: V767 लूप के अंदर एक स्थिर इंडेक्स द्वारा 'फाइल' एरे के तत्व तक संदिग्ध पहुंच। sprite_frames_editor_plugin.cpp 602

लूप लूप के सभी पुनरावृत्तियों पर एक ही फ़ाइल को संसाधित करता है। यहाँ टाइप करें:

 String file = files[0]; 

होना चाहिए:

 String file = files[i]; 

अन्य त्रुटियां

त्रुटि N16

 CSGBrush *CSGBox::_build_brush() { .... for (int i = 0; i < 6; i++) { .... if (i < 3) face_points[j][(i + k) % 3] = v[k] * (i >= 3 ? -1 : 1); else face_points[3 - j][(i + k) % 3] = v[k] * (i >= 3 ? -1 : 1); .... } .... } 

PVS-Studio विश्लेषक तुरंत इस कोड पर दो प्रतिक्रियाएँ देता है:

• V547 CWE-570 एक्सप्रेशन 'i> = 3' हमेशा गलत होता है। csg_shape.cpp 939
• V547 CWE-571 एक्सप्रेशन 'i> = 3' हमेशा सच होता है। csg_shape.cpp 941

वास्तव में, दोनों भावों में यह गुदगुदी ऑपरेटर बहुत अजीब लगता है:

 i >= 3 ? -1 : 1 

एक मामले में, स्थिति हमेशा सच होती है, और दूसरे में यह गलत है। यह कहना मुश्किल है कि यह कोड सही कैसे दिखना चाहिए। शायद यह बेमानी है और इसे इस तरह लिखा जा सकता है:

 for (int i = 0; i < 6; i++) { .... if (i < 3) face_points[j][(i + k) % 3] = v[k]; else face_points[3 - j][(i + k) % 3] = -v[k]; .... } 

मैं गलत हो सकता हूं, और कोड को पूरी तरह से अलग करने की आवश्यकता है।

त्रुटि N17

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

 bool CanvasItemEditor::_get_bone_shape(....) { .... Node2D *from_node = Object::cast_to<Node2D>( ObjectDB::get_instance(bone->key().from)); .... if (!from_node->is_inside_tree()) return false; //may have been removed if (!from_node) return false; .... } 

पीवीएस-स्टूडियो चेतावनी: V595 CWE-476 'from_node' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 565, 567. कैनवस_टाइम_डिटर_प्लगिन.कैप 565

From_node पॉइंटर को पहले is_inside_tree फ़ंक्शन को कॉल करने के लिए dereferenced जाता है , और उसके बाद ही इसे nullptr समानता के लिए जांचा जाता है। चेक स्वैप किए जाने चाहिए:

 if (!from_node) return false; if (!from_node->is_inside_tree()) return false; //may have been removed 

त्रुटि N18

 enum JoystickList { .... JOY_AXIS_MAX = 10, .... }; static const char *_axes[] = { "Left Stick X", "Left Stick Y", "Right Stick X", "Right Stick Y", "", "", "L2", "R2" }; int InputDefault::get_joy_axis_index_from_string(String p_axis) { for (int i = 0; i < JOY_AXIS_MAX; i++) { if (p_axis == _axes[i]) { return i; } } ERR_FAIL_V(-1); } 

पीवीएस-स्टूडियो चेतावनी: V557 CWE-125 ऐरे ओवररन संभव है। 'I' इंडेक्स का मान 9. input_default.cpp 1119 तक पहुंच सकता है

_Axes सरणी में आठ तत्व होते हैं। इस स्थिति में, निरंतर JOY_AXIS_MAX , जो लूप के पुनरावृत्तियों की संख्या निर्धारित करता है, 10. यह पता चलता है कि लूप सरणी सीमा से परे जाता है।

त्रुटि N19

और अंतिम बहुत अजीब फ़ंक्शन, जो, जाहिरा तौर पर, कुछ का परीक्षण करने के लिए डिज़ाइन किया गया है। फ़ंक्शन लंबा है, इसलिए मैं इसे एक तस्वीर के रूप में दूंगा (चित्र पर क्लिक करें विस्तार करने के लिए)।

पीवीएस-स्टूडियो चेतावनी: V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। test_math.cpp 457

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

शायद, निश्चित रूप से, यह किसी प्रकार का चालाक विचार है। लेकिन यह मुझे लगता है कि यह संयोग से हुआ है और कोड तय किया जाना चाहिए।

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

निष्कर्ष

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

आपका ध्यान के लिए धन्यवाद। मैं सभी को डाउनलोड करने और अपने स्वयं के प्रोजेक्ट का परीक्षण करने के लिए पीवीएस-स्टूडियो के स्थिर विश्लेषण का प्रयास करने के लिए आमंत्रित करता हूं।

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