WinForms: त्रुटियां, होम्स

हम Microsoft प्रोजेक्ट्स में बग ढूंढना पसंद करते हैं। क्यों? यह सरल है: उनकी परियोजनाएं आमतौर पर जांचने में आसान होती हैं (विजुअल स्टूडियो वातावरण में काम तुरंत किया जा सकता है, जिसके लिए पीवीएस-स्टूडियो में एक सुविधाजनक प्लग-इन है) और उनमें कुछ त्रुटियां हैं। इसलिए, काम का सामान्य एल्गोरिथ्म इस प्रकार है: एमएस से एक खुली परियोजना को ढूंढें और डाउनलोड करें; इसे देखें; दिलचस्प गलतियाँ चुनें; सुनिश्चित करें कि वे कम हैं; डेवलपर्स की प्रशंसा करने के लिए भूल के बिना एक लेख लिखें। वाह! विन-विन-विन: इसमें थोड़ा समय लगा, ब्लॉग पर नई सामग्रियों को देखने के लिए मैनुअल को खुशी है, और कर्म सही क्रम में है। लेकिन इस बार कुछ गड़बड़ हो गई। आइए देखें कि विंडोज फॉर्म के स्रोत कोड में क्या दिलचस्प पाया गया और क्या इस बार माइक्रोसॉफ्ट की प्रशंसा की जानी चाहिए।

परिचय

दिसंबर 2018 की शुरुआत में, Microsoft ने .NET कोर 3 पूर्वावलोकन 1 की रिलीज की घोषणा की। थोड़ी देर पहले (लगभग अक्टूबर के मध्य से), GitHub ने विंडोज फॉर्मेट्स के लिए सोर्स कोड के प्रकाशन पर सक्रिय कार्य शुरू किया। .NET कोर यूआई प्लेटफॉर्म विंडोज डेस्कटॉप एप्लिकेशन बनाने के लिए। आप यहां कमिटमेंट के आंकड़े देख सकते हैं। अब कोई भी रिव्यू के लिए WinForms सोर्स कोड डाउनलोड कर सकता है।

मैंने पीवीएस-स्टूडियो का उपयोग करते हुए त्रुटियों को देखने के लिए स्रोत भी डाउनलोड किए। जाँच में कठिनाई नहीं हुई। आवश्यक: विज़ुअल स्टूडियो 2019, .NET कोर 3.0 एसडीके पूर्वावलोकन, पीवीएस-स्टूडियो। और अब विश्लेषक चेतावनी लॉग प्राप्त हुआ है।

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

क्या पाया था? हाई और मीडियम कॉन्फिडेंस लेवल (२४ ९ और ५ respectively४, क्रमशः) की ३३ चेतावनियाँ १६ cs० सीएस फाइलों में कोड की ५४०,००० लाइनों (खाली को छोड़कर) के लिए जारी की गई थीं। और हां, परंपरा के अनुसार, मैंने परीक्षणों की जांच नहीं की और कम आत्मविश्वास के स्तर (215 जारी किए गए) की चेतावनी पर विचार नहीं किया। मेरी पिछली टिप्पणियों के अनुसार, एमएस से परियोजना के लिए बहुत सारी चेतावनियाँ हैं। लेकिन सभी चेतावनी त्रुटियां नहीं हैं।

इस परियोजना के लिए, झूठी सकारात्मक की संख्या लगभग 30% थी। लगभग 20% मामलों में, मैं अभी इस बारे में सटीक निष्कर्ष नहीं दे सका कि यह गलती है या नहीं, क्योंकि मैं कोड से अच्छी तरह से परिचित नहीं हूं। खैर, कम से कम 20% त्रुटियां जो मुझे याद आती हैं, उन्हें मानव कारक के लिए जिम्मेदार ठहराया जा सकता है: जल्दबाजी, थकान, आदि। विपरीत प्रभाव भी संभव है: वैसे, मैंने कुछ इसी तरह के ट्रिगर के माध्यम से देखा, जिनमें से संख्या 70-80 तक पहुंच सकती है, एक के माध्यम से कभी-कभी उन त्रुटियों की संख्या बढ़ सकती है जिन्हें मैंने वास्तविक माना था।

किसी भी मामले में, 30% चेतावनी वास्तविक त्रुटियों को दर्शाती है, जो एक बहुत बड़ा प्रतिशत है, यह देखते हुए कि विश्लेषक पूर्व-कॉन्फ़िगर नहीं किया गया है।

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

त्रुटियों

PVS-Studio: V3003 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइन: 213, 224. ButtonStandardAdapter.cs 213

void PaintWorker(PaintEventArgs e, bool up, CheckState state) { up = up && state == CheckState.Unchecked; .... if (up & IsHighContrastHighlighted()) { .... } else if (up & IsHighContrastHighlighted()) { .... } else { .... } .... } 

अगर और में अगर ब्लॉक करता है, तो उसी स्थिति की जाँच की जाती है। यह कॉपी-पेस्ट जैसा दिखता है। क्या यह गलती है? यदि आप IsHighContrastHighlighted विधि की घोषणा को देखते हैं , तो संदेह है:

 protected bool IsHighContrastHighlighted() { return SystemInformation.HighContrast && Application.RenderWithVisualStyles && (Control.Focused || Control.MouseIsOver || (Control.IsDefault && Control.Enabled)); } 

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

PVS-Studio: V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। RichTextBox.cs 1018

 public int SelectionCharOffset { get { int selCharOffset = 0; .... NativeMethods.CHARFORMATA cf = GetCharFormat(true); // if the effects member contains valid info if ((cf.dwMask & RichTextBoxConstants.CFM_OFFSET) != 0) { selCharOffset = cf.yOffset; // <= } else { // The selection contains characters of different offsets, // so we just return the offset of the first character. selCharOffset = cf.yOffset; // <= } .... } .... } 

और यहाँ कॉपी-पेस्ट त्रुटि निश्चित रूप से की गई है। शर्त के बावजूद, selCharOffset वैरिएबल को हमेशा समान मूल्य मिलेगा।

WinForms कोड में दो और समान त्रुटियां थीं:

• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। स्प्लिटकोन्टर। एससी 1700
• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। ToolstripProfessionalRenderer.cs 371

PVS-Studio: V3008 चर को क्रमिक रूप से दो बार दिया जाता है। शायद यह एक गलती है। लाइनों की जाँच करें: 681, 680. ProfessionalColorTable.cs 681

 internal void InitSystemColors(ref Dictionary<KnownColors, Color> rgbTable) { .... rgbTable[ProfessionalColorTable.KnownColors.msocbvcrCBBdrOuterDocked] = buttonFace; rgbTable[ProfessionalColorTable.KnownColors.msocbvcrCBBdrOuterDocked] = buttonShadow; .... } 

विधि rgbTable शब्दकोश पॉप्युलेट करता है। विश्लेषक ने कोड के एक टुकड़े को इंगित किया जहां दो अलग-अलग मान समान कुंजी पर क्रमिक रूप से लिखे गए हैं। और सबकुछ ठीक हो जाएगा, लेकिन इस पद्धति में ऐसी 16 और जगहें थीं। यह अब एक त्रुटि की तरह नहीं दिखता है। लेकिन ऐसा क्यों, मेरे लिए यह एक रहस्य बना हुआ है। मुझे ऑटोजेनरेटेड कोड के संकेत नहीं मिले। संपादक में, यह इस तरह दिखता है:

मैं एक सूची के साथ पहले दस ऑपरेशन देगा:

1. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 785, 784। ProfessionalColorTable.cs 785
2. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 787, 786। ProfessionalColorTable.cs 787
3. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 789, 788
4. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 791, 790. प्रोफेशनलकॉन्फ़र्टेबल .cs 791
5. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 797, 796. प्रोफेशनलकॉन्स्टेबल .cs 797
6. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 799, 798. प्रोफेशनलकॉन्स्टेबल .cs 799
7. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 807, 806. प्रोफेशनल क्योरबल .cs 807
8. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 815, 814। ProfessionalColorTable.cs 815
9. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 817, 816
10. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच रेखाएँ: 823, 822. प्रोफेशनलकॉन्स्टेबल .cs 823

PVS-Studio: V3011 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी स्थिति हमेशा झूठी होती है। लाइनों की जाँच करें: 5242, 5240। DataGrid.cs 5242

 private void CheckHierarchyState() { if (checkHierarchy && listManager != null && myGridTable != null) { if (myGridTable == null) // <= { // there was nothing to check return; } for (int j = 0; j < myGridTable.GridColumnStyles.Count; j++) { DataGridColumnStyle gridColumn = myGridTable.GridColumnStyles[j]; } checkHierarchy = false; } } 

रिटर्न स्टेटमेंट कभी निष्पादित नहीं किया जाएगा। सबसे अधिक संभावना है, हालत myGridTable! = बाहरी में अशक्त अगर ब्लॉक को बाद में फिर से जोड़ने के दौरान जोड़ा गया था। और अब myGridTable == null की जाँच करना व्यर्थ है। कोड की गुणवत्ता में सुधार करने के लिए, इस चेक को हटा दें।

PVS-Studio: V3019 संभवतः एक गलत वैरिएबल की तुलना 'कीवर्ड' के रूप में उपयोग करके टाइप रूपांतरण के बाद की जाती है। चर 'वाम', 'cscLeft' की जाँच करें। TypeCodeDomSerializer.cs 611

PVS-Studio: V3019 संभवतः एक गलत वैरिएबल की तुलना 'कीवर्ड' के रूप में उपयोग करके टाइप रूपांतरण के बाद की जाती है। चर 'सही', 'cscRight' की जाँच करें। TypeCodeDomSerializer.cs 615

 public int Compare(object left, object right) { OrderedCodeStatementCollection cscLeft = left as OrderedCodeStatementCollection; OrderedCodeStatementCollection cscRight = right as OrderedCodeStatementCollection; if (left == null) { return 1; } else if (right == null) { return -1; } else if (right == left) { return 0; } return cscLeft.Order - cscRight.Order; // <= } 

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

कोड को ठीक करने के लिए, cscLeft / cscRight को बाएं / दाएं के बजाय हर जगह इस्तेमाल किया जाना चाहिए।

पीवीएस-स्टूडियो: वी 3020 एक लूप के भीतर बिना शर्त 'ब्रेक'। SelectionService.cs 421

 void ISelectionService.SetSelectedComponents( ICollection components, SelectionTypes selectionType) { .... // Handle the click case object requestedPrimary = null; int primaryIndex; if (fPrimary && 1 == components.Count) { foreach (object o in components) { requestedPrimary = o; if (o == null) { throw new ArgumentNullException(nameof(components)); } break; } } .... } 

यह टुकड़ा "गंध के साथ" कोड को संदर्भित करता है, बल्कि। यहां कोई गलती नहीं है। लेकिन सवाल यह उठता है कि जिस तरह से फोरचेक चक्र का आयोजन किया गया है। यहां इसकी आवश्यकता क्यों है - यह स्पष्ट है: संग्रह के तत्वों को निकालने की आवश्यकता के कारण, ICollection के रूप में पारित किया गया। लेकिन लूप में क्यों, मूल रूप से एक एकल पुनरावृत्ति ( घटकों के संग्रह में एक तत्व की उपस्थिति) के लिए डिज़ाइन किया गया था , ब्रेक के रूप में एक अतिरिक्त सुरक्षा जाल की आवश्यकता थी? शायद, जवाब पर विचार किया जा सकता है: "यह ऐतिहासिक रूप से विकसित हुआ है।" कोड बदसूरत लग रहा है।

PVS-Studio: V3022 एक्सप्रेशन 'ocxState! = Null' हमेशा सच होता है। AxHost.cs 2186

 public State OcxState { .... set { .... if (value == null) { return; } .... ocxState = value; if (ocxState != null) // <= { axState[manualUpdate] = ocxState._GetManualUpdate(); licenseKey = ocxState._GetLicenseKey(); } else { axState[manualUpdate] = false; licenseKey = null; } .... } } 

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

PVS-Studio: V3027 वैरिएबल 'e' को तार्किक अभिव्यक्ति में उपयोग किया गया था, क्योंकि यह उसी तार्किक अभिव्यक्ति में शून्य के खिलाफ सत्यापित था। ImageEditor.cs 99

 public override object EditValue(....) { .... ImageEditor e = ....; Type myClass = GetType(); if (!myClass.Equals(e.GetType()) && e != null && myClass.IsInstanceOfType(e)) { .... } .... } 

हालत में चर ई पहले प्रयोग किया जाता है, और फिर अशक्त असमानता के लिए जाँच की जाती है। हाय, NullReferenceException ।

इसी तरह की एक और त्रुटि:

PVS-Studio: V3027 चर 'dropDownItem' का तार्किक अभिव्यक्ति में उपयोग किया गया था, क्योंकि यह उसी तार्किक अभिव्यक्ति में शून्य के खिलाफ सत्यापित था। ToolStripMenuItemDesigner.cs 1351

 internal void EnterInSituEdit(ToolStripItem toolItem) { .... ToolStripDropDownItem dropDownItem = toolItem as ToolStripDropDownItem; if (!(dropDownItem.Owner is ToolStripDropDownMenu) && dropDownItem != null && dropDownItem.Bounds.Width < commitedEditorNode.Bounds.Width) { .... } .... } 

पिछले ड्रॉप के समान एक स्थिति, केवल चर ड्रॉपडाउन के साथ । मुझे लगता है कि इस तरह की त्रुटियां रिफैक्टरिंग के दौरान असावधानी के परिणामस्वरूप दिखाई देती हैं। शायद हालत का हिस्सा ! (DropDownItem.Owner ToolStripDropDownMenu है) को बाद में कोड में जोड़ा गया था।

PVS-Studio: V3030 आवर्ती जाँच। 'कॉलमकाउंट> 0' की स्थिति पहले से ही 3900 लाइन में सत्यापित की गई थी। सूची दृश्य। 3903

 internal ColumnHeader InsertColumn( int index, ColumnHeader ch, bool refreshSubItems) { .... // Add the column to our internal array int columnCount = (columnHeaders == null ? 0 : columnHeaders.Length); if (columnCount > 0) { ColumnHeader[] newHeaders = new ColumnHeader[columnCount + 1]; if (columnCount > 0) { System.Array.Copy(columnHeaders, 0, newHeaders, 0, columnCount); } .... } .... } 

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

PVS-Studio: V3061 पैरामीटर 'lprcClipRect' का उपयोग करने से पहले हमेशा विधि निकाय में फिर से लिखा जाता है। WebBrowserSiteBase.cs 281

 int UnsafeNativeMethods.IOleInPlaceSite.GetWindowContext( out UnsafeNativeMethods.IOleInPlaceFrame ppFrame, out UnsafeNativeMethods.IOleInPlaceUIWindow ppDoc, NativeMethods.COMRECT lprcPosRect, NativeMethods.COMRECT lprcClipRect, NativeMethods.tagOIFI lpFrameInfo) { ppDoc = null; ppFrame = Host.GetParentContainer(); lprcPosRect.left = Host.Bounds.X; lprcPosRect.top = Host.Bounds.Y; .... lprcClipRect = WebBrowserHelper.GetClipRect(); // <= if (lpFrameInfo != null) { lpFrameInfo.cb = Marshal.SizeOf<NativeMethods.tagOIFI>(); lpFrameInfo.fMDIApp = false; .... } return NativeMethods.S_OK; } 

असभ्य गलती। हां, lprcClipRect पैरामीटर को किसी भी तरह से उपयोग किए बिना, वास्तव में एक नए मूल्य के साथ आरंभ किया जाता है। लेकिन इसमें क्या परिणाम होता है? मुझे लगता है कि कॉलिंग कोड में, इस पैरामीटर के माध्यम से पारित लिंक अपरिवर्तित रहेगा, हालांकि इसका उद्देश्य अलग था। वास्तव में, इस विधि में अन्य चर के साथ काम करना देखें। यहां तक ​​कि इसका नाम ("गेट" उपसर्ग) संकेत देता है कि पारित किए गए मापदंडों के माध्यम से विधि के अंदर कुछ आरंभीकरण किया जाएगा। और इसलिए यह है। पहले दो पैरामीटर ( ppFrame और ppDoc ) आउट मॉडिफायर के साथ पास किए जाते हैं और नए मान प्राप्त करते हैं। लिंक lprcPosRect और lpFrameInfo का उपयोग वर्ग के क्षेत्रों तक पहुंचने और उन्हें आरंभ करने के लिए किया जाता है। और केवल lprcClipRect सामान्य सूची से बाहर हो जाता है। सबसे अधिक संभावना है, इस पैरामीटर के लिए आउट या रेफ संशोधक आवश्यक है।

PVS-Studio: V3066 संभावित गलत आदेशों का तर्क 'AdjustCellBorderStyle' पद्धति से पारित हुआ:'FirstDisplayedRow 'और'FirstDisplayedColumn'। DataGridViewComboBoxCell.cs 1934

 protected override void OnMouseMove(DataGridViewCellMouseEventArgs e) { .... dgvabsEffective = AdjustCellBorderStyle( DataGridView.AdvancedCellBorderStyle, dgvabsPlaceholder, singleVerticalBorderAdded, singleHorizontalBorderAdded, isFirstDisplayedRow, // <= isFirstDisplayedColumn); // <= .... } 

विश्लेषक को संदेह था कि अंतिम दो तर्क मिश्रित थे। चलिए एडजस्टमेंट कंट्रोलर विधि की घोषणा पर एक नज़र डालते हैं :

 public virtual DataGridViewAdvancedBorderStyle AdjustCellBorderStyle( DataGridViewAdvancedBorderStyledataGridViewAdvancedBorderStyleInput, DataGridViewAdvancedBorderStyle dataGridViewAdvancedBorderStylePlaceholder, bool singleVerticalBorderAdded, bool singleHorizontalBorderAdded, bool isFirstDisplayedColumn, bool isFirstDisplayedRow) { .... } 

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

पीवीएस-स्टूडियो: 'LOCALE_USER_DEFAULT' वैरिएबल को प्रारंभ करते समय V3070 Uninitialized चर 'LANG_USER_DEFAULT' का उपयोग किया जाता है। NativeMethods.cs 890

 internal static class NativeMethods { .... public static readonly int LOCALE_USER_DEFAULT = MAKELCID(LANG_USER_DEFAULT); public static readonly int LANG_USER_DEFAULT = MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT); .... } 

एक दुर्लभ गलती। वर्ग क्षेत्रों के आरंभ के क्रम को मिलाया जाता है। LOCALE_USER_DEFAULT फ़ील्ड के मान की गणना करने के लिए, LANG_USER_DEFAULT फ़ील्ड का उपयोग करें, जो अभी तक आरंभीकृत नहीं है और इसका मान 0. है। वैसे, LANG_USER_DEFAULT फ़ील्ड का उपयोग कोड में कहीं और नहीं किया गया है। मैं बहुत आलसी नहीं था और एक छोटा सा कंसोल प्रोग्राम लिखा था जो स्थिति का अनुकरण करता है। WinForms कोड में उपयोग किए जाने वाले कुछ स्थिरांक के मूल्यों के बजाय, मैंने उनके वास्तविक मूल्यों को प्रतिस्थापित किया है:

 internal static class NativeMethods { public static readonly int LOCALE_USER_DEFAULT = MAKELCID(LANG_USER_DEFAULT); public static readonly int LANG_USER_DEFAULT = MAKELANGID(0x00, 0x01); public static int MAKELANGID(int primary, int sub) { return ((((ushort)(sub)) << 10) | (ushort)(primary)); } public static int MAKELCID(int lgid) { return MAKELCID(lgid, 0x0); } public static int MAKELCID(int lgid, int sort) { return ((0xFFFF & lgid) | (((0x000f) & sort) << 16)); } } class Program { static void Main() { System.Console.WriteLine(NativeMethods.LOCALE_USER_DEFAULT); } } 

लॉन्च के परिणामस्वरूप, निम्नलिखित कंसोल पर प्रदर्शित किया जाएगा: 0. अब हम LOCALE_USER_DEFAULT और LANG_USER_DEFAULT फ़ील्ड की घोषणा को स्वैप करते हैं । इस रूप में कार्यक्रम का परिणाम: 1024। मुझे लगता है कि यहां टिप्पणी करने के लिए और कुछ नहीं है।

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । 'सेस' का निरीक्षण करने पर विचार करें। कोडडोमसेरिलाइज़रबेस .cs 562

 protected void DeserializeStatement( IDesignerSerializationManager manager, CodeStatement statement) { .... CodeExpressionStatement ces = statement as CodeExpressionStatement; if (ces != null) { .... } else { .... DeserializeExpression(manager, null, ces.Expression); // <= .... } .... } 

कोड है कि "गिर" चाहिए पर्याप्त स्थिर है, क्योंकि आप दूसरी शाखा में बस प्राप्त कर सकते हैं जब ces संदर्भ शून्य है ।

इसी तरह का एक और उदाहरण:

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । 'कॉम्बो बॉक्स' का निरीक्षण करने पर विचार करें। ComboBox.cs 6610

 public void ValidateOwnerDrawRegions(ComboBox comboBox, ....) { .... if (comboBox != null) { return; } Rectangle topOwnerDrawArea = new Rectangle(0, 0, comboBox.Width, innerBorder.Top); .... } 

विरोधाभासी कोड। जाहिरा तौर पर, उन्होंने अगर (कॉम्बोबॉक्स == अशक्त) के बजाय (comboBox! = Null) लिखकर परीक्षण को मिलाया। और इसलिए - हम अगले NullReferenceException प्राप्त करेंगे।

हमने दो बिल्कुल स्पष्ट त्रुटियों V3080 की जांच की, जहां आप विधि के भीतर अशक्त संदर्भों के संभावित उपयोग की स्थिति को नेत्रहीन रूप से ट्रैक कर सकते हैं। लेकिन V3080 डायग्नोस्टिक्स बहुत अधिक बुद्धिमान हैं और विधि कॉल की श्रृंखलाओं के लिए समान त्रुटियों की तलाश कर सकते हैं। इतनी देर पहले नहीं, हमने डेटाफ्लो और इंटरप्रोडेक्टोरल विश्लेषण के तंत्र को काफी मजबूत किया। आप इसके बारे में लेख " Nullable Reference Types in C # 8.0 और Static Analysis " में पढ़ सकते हैं। और यहाँ WinForms में एक समान त्रुटि पाई गई है:

PVS- स्टूडियो: V3080 'n.TT' पर विधि के अंदर संभव अशांति को रोकने। 1 तर्क का निरीक्षण करने पर विचार करें: contentReader। ResXResourceReader.cs 267

 private void EnsureResData() { .... XmlTextReader contentReader = null; try { if (fileContents != null) { contentReader = new XmlTextReader(....); } else if (reader != null) { contentReader = new XmlTextReader(....); } else if (fileName != null || stream != null) { .... contentReader = new XmlTextReader(....); } SetupNameTable(contentReader); // <= .... } finally { .... } .... } 

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

 private void SetupNameTable(XmlReader reader) { reader.NameTable.Add(ResXResourceWriter.TypeStr); reader.NameTable.Add(ResXResourceWriter.NameStr); .... } 

यह संभावित असुरक्षित कोड है।

और एक और त्रुटि, जहां एक समस्या की पहचान करने के लिए विश्लेषक को कॉल की एक श्रृंखला से गुजरना पड़ा:

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । निरीक्षण 'लेआउट' पर विचार करें। DockAndAnchorLayout.cs 156

 private static Rectangle GetAnchorDestination( IArrangedElement element, Rectangle displayRect, bool measureOnly) { .... AnchorInfo layout = GetAnchorInfo(element); int left = layout.Left + displayRect.X; .... } 

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

 private static AnchorInfo GetAnchorInfo(IArrangedElement element) { return (AnchorInfo)element.Properties.GetObject(s_layoutInfoProperty); } public object GetObject(int key) => GetObject(key, out _); public object GetObject(int key, out bool found) { short keyIndex = SplitKey(key, out short element); if (!LocateObjectEntry(keyIndex, out int index)) { found = false; return null; } // We have found the relevant entry. See if // the bitmask indicates the value is used. if (((1 << element) & s_objEntries[index].Mask) == 0) { found = false; return null; } found = true; switch (element) { case 0: return s_objEntries[index].Value1; .... default: Debug.Fail("Invalid element obtained from LocateObjectEntry"); return null; } } 

दरअसल, कुछ मामलों में, कॉल श्रंखला को बंद करने वाला GetObject तरीका शून्य हो जाएगा, जो बिना किसी अतिरिक्त चेक के कॉलिंग विधि को पास कर देगा। शायद, GetAnchorDestination विधि ऐसी स्थिति के लिए प्रदान करनी चाहिए।

WinForms कोड में 70 से अधिक ऐसी कुछ त्रुटियां थीं। वे सभी समान हैं और मैं लेख में उनका वर्णन नहीं दूंगा।

पीवीएस-स्टूडियो: V3091 अनुभवजन्य विश्लेषण। यह संभव है कि एक टाइपो स्ट्रिंग शाब्दिक के अंदर मौजूद है: "ShowCheckMargin"। 'ShowCheckMargin' शब्द संदिग्ध है। संपत्ति नाम। 136

 internal class PropertyNames { .... public static readonly string ShowImageMargin = "ShowCheckMargin"; ... public static readonly string ShowCheckMargin = "ShowCheckMargin"; .... } 

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

यह ऐसी त्रुटियों का पता लगाना है जो स्थैतिक विश्लेषण उपकरणों की शक्ति और असीम देखभाल को प्रदर्शित करता है।

PVS-Studio: V3095 नल के खिलाफ सत्यापित होने से पहले ' currentForm ' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 3386, 3404. Application.cs 3386

 private void RunMessageLoopInner(int reason, ApplicationContext context) { .... hwndOwner = new HandleRef( null, UnsafeNativeMethods.GetWindowLong( new HandleRef(currentForm, currentForm.Handle), // <= NativeMethods.GWL_HWNDPARENT)); .... if (currentForm != null && ....) .... } 

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

इसी तरह की एक और त्रुटि:

पीवीएस-स्टूडियो: V3095 'बैकग्राउंडब्रश' ऑब्जेक्ट का उपयोग इससे पहले किया गया था कि इसे शून्य के खिलाफ सत्यापित किया गया था। जाँच रेखाएँ: 2331, 2334। DataGrid.cs 2331

 public Color BackgroundColor { .... set { .... if (!value.Equals(backgroundBrush.Color)) // <= { if (backgroundBrush != null && BackgroundBrush != DefaultBackgroundBrush) .... } } } 

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

PVS-Studio: V3125 '_propInfo' ऑब्जेक्ट का उपयोग किया गया था और इसे विभिन्न निष्पादन शाखाओं में नल के खिलाफ सत्यापित किया गया था। चेक लाइनें: 996, 982. बाइंडिंग.के 996

 private void SetPropValue(object value) { .... if (....) { if .... else if (_propInfo != null) .... } else { _propInfo.SetValue(_control, value); } .... } 

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

और इसी तरह की एक और त्रुटि:

PVS-Studio: V3125 'मालिक' ऑब्जेक्ट का उपयोग नल के खिलाफ सत्यापित होने के बाद किया गया था। रेखाएँ जांचें: 64, 60. फ्लैटबटन एपियरेंस .cs 64

 public int BorderSize { .... set { .... if (owner != null && owner.ParentInternal != null) { LayoutTransaction.DoLayoutIf(....); } owner.Invalidate(); // <= .... } } 

सौंदर्य। लेकिन यह एक बाहरी शोधकर्ता के दृष्टिकोण से है। दरअसल, इन दोनों V3125s के अलावा, विश्लेषक को WinForms कोड में 50 से अधिक समान पैटर्न मिले। डेवलपर्स के पास काम करने के लिए है।

और अंत में - बल्कि एक दिलचस्प त्रुटि, मेरी राय में।

PVS-Studio: V3137 'hCurrentFont' वैरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। DeviceContext2.cs 241

 sealed partial class DeviceContext : .... { WindowsFont selectedFont; .... internal void DisposeFont(bool disposing) { if (disposing) { DeviceContexts.RemoveDeviceContext(this); } if (selectedFont != null && selectedFont.Hfont != IntPtr.Zero) { IntPtr hCurrentFont = IntUnsafeNativeMethods.GetCurrentObject( new HandleRef(this, hDC), IntNativeMethods.OBJ_FONT); if (hCurrentFont == selectedFont.Hfont) { // select initial font back in IntUnsafeNativeMethods.SelectObject(new HandleRef(this, Hdc), new HandleRef(null, hInitialFont)); hCurrentFont = hInitialFont; // <= } selectedFont.Dispose(disposing); selectedFont = null; } } .... } 

आइए देखें कि विश्लेषक ने क्या चेतावनी दी, और इस तथ्य को क्यों कि एक चर को एक मान सौंपा गया है, लेकिन इसका उपयोग आगे की विधि में नहीं किया गया है, एक समस्या का संकेत दे सकता है।

DeviceContext2.cs फ़ाइल में एक आंशिक वर्ग घोषित किया गया है। DisposeFont विधि का उपयोग ग्राफिक्स के साथ काम करने के बाद संसाधनों को मुक्त करने के लिए किया जाता है: डिवाइस संदर्भ और फ़ॉन्ट। एक बेहतर समझ के लिए, मैंने संपूर्ण डिस्पोज़ोंट विधि प्रदान की है। स्थानीय चर hCurrentFont पर ध्यान दें । समस्या यह है कि इस चर को एक विधि में घोषित करना उसी नाम के वर्ग क्षेत्र को छुपाता है। मुझे DeviceContext क्लास के दो तरीके मिले जहाँ hCurrentFont नामक फ़ील्ड का उपयोग किया जाता है :

 public IntPtr SelectFont(WindowsFont font) { .... hCurrentFont = font.Hfont; .... } public void ResetFont() { .... hCurrentFont = hInitialFont; } 

ResetFont विधि पर एक नज़र डालें। अंतिम पंक्ति वहाँ है जो डिस्पोज़न्ट विधि नेस्टेड में करती है यदि ब्लॉक (विश्लेषक इस स्थान पर इंगित करता है)। और उसी नाम का यह hCurrentFont फ़ील्ड DeviceContext.cs फ़ाइल में आंशिक वर्ग के किसी अन्य भाग में घोषित किया गया था:

 sealed partial class DeviceContext : .... { .... IntPtr hInitialFont; .... IntPtr hCurrentFont; // <= .... } 

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

निष्कर्ष

इसलिए, इस बार मुझे एमएस को थोड़ा डांटना होगा। WinForms में बहुत सारी त्रुटियां थीं जिनके लिए डेवलपर्स का ध्यान आकर्षित करना आवश्यक है। शायद यह कुछ भीड़ के कारण है जिसके साथ MS .NET कोर 3 और घटकों पर काम कर रहा है, जिसमें WinForms भी शामिल है। मेरी राय में, WinForms कोड अभी भी "नम" है, लेकिन मुझे उम्मीद है कि स्थिति जल्द ही बेहतर के लिए बदल जाएगी।

बड़ी संख्या में त्रुटियों का दूसरा कारण यह हो सकता है कि हमारे विश्लेषक को उनकी तलाश करना बेहतर लगा :)।

वैसे, मेरे सहयोगी सर्गेई वासिलिव द्वारा एक लेख जल्द ही प्रकाशित किया जाएगा जिसमें वह खोजता है और .NET कोर पुस्तकालयों के कोड में काफी कुछ समस्याएं पाता है। मुझे उम्मीद है कि उनका काम .NET प्लेटफॉर्म के प्रदर्शन को बेहतर बनाने में भी योगदान देगा, क्योंकि हम हमेशा डेवलपर्स के लिए उनकी परियोजनाओं के विश्लेषण के परिणामों को संप्रेषित करने का प्रयास करते हैं।

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

सभी साफ कोड!

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