छठा क्रोमियम टेस्ट, आफ्टरवर्ड

2018 की शुरुआत में, क्रोमियम परियोजना के स्रोत कोड के छठे सत्यापन के लिए समर्पित हमारे ब्लॉग पर लेखों की एक श्रृंखला दिखाई दी। चक्र में उनकी रोकथाम के लिए त्रुटियों और सिफारिशों के लिए समर्पित 8 लेख शामिल हैं। दो लेखों ने गर्मजोशी से चर्चा की है, और अब तक मुझे उनमें संबोधित विषयों पर शायद ही कभी टिप्पणी मिली हो। शायद, कुछ अतिरिक्त स्पष्टीकरण दिए जाने चाहिए और, जैसा कि वे कहते हैं, i को डॉट करें।

क्रोमियम परियोजना के स्रोत कोड के अगले सत्यापन के लिए समर्पित लेखों की एक श्रृंखला के लेखन में एक वर्ष बीत चुका है:

1. क्रोमियम: छठी परियोजना की जांच और 250 बग
2. सुंदर क्रोमियम और अनाड़ी याद
3. टूटना और गिरना
4. क्रोमियम: मेमोरी लीक
5. क्रोमियम टाइपो
6. क्रोमियम: गलत डेटा का उपयोग करना
7. यह जानना महत्वपूर्ण है कि मॉलोक फ़ंक्शन क्या लौटा
8. क्रोमियम: अन्य त्रुटियां

मेमसेट और मल्लोक पर लेखों का कारण बना है, और कारण बनता है, चर्चा जो मुझे अजीब लगती है। जाहिर है, इस तथ्य के कारण कुछ गलतफहमी थी कि मैंने अपने विचारों को स्पष्ट रूप से तैयार नहीं किया। मैंने इन लेखों पर लौटने और कुछ स्पष्टीकरण करने का फैसला किया।

memset

चलिए शुरुआत करते हैं लेख के बारे में, क्योंकि यहां सब कुछ सरल है। संरचनाओं को प्रारंभिक करने के लिए सबसे अच्छा विवाद था। काफी सारे प्रोग्रामर्स ने लिखा कि यह सलाह है कि न लिखने की सलाह दें:

HDHITTESTINFO hhti = {}; 

और इसलिए:

 HDHITTESTINFO hhti = { 0 }; 

तर्क:

1. {} की तुलना में कोड पढ़ते समय {0} निर्माण आसान है।
2. {}} निर्माण {} से अधिक सहज है। यही है, 0 पता चलता है कि संरचना शून्य से भर गई है।

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

दृश्यता के बारे में। मुझे लगता है कि यह स्वाद और आदत का मामला है। मुझे नहीं लगता है कि घुंघराले ब्रेस के अंदर 0 की उपस्थिति मौलिक रूप से स्थिति को बदल देती है।

लेकिन दूसरे तर्क के साथ मैं बिल्कुल सहमत नहीं हूं। {0} जैसा रिकॉर्ड कोड को गलत समझने का कारण देता है। उदाहरण के लिए, आप गणना कर सकते हैं कि यदि आप 0 को 1 के साथ प्रतिस्थापित करते हैं, तो सभी क्षेत्रों को इकाइयों में आरंभीकृत किया जाएगा। इसलिए, लेखन की यह शैली उपयोगी से अधिक हानिकारक है।

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

V1009। सरणी आरंभीकरण की जाँच करें। केवल पहला तत्व स्पष्ट रूप से आरंभिक है।

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

संदिग्ध कोड के एक उदाहरण पर विचार करें:

 int arr[3] = {1}; 

शायद प्रोग्रामर को एक इकाइयों से मिलकर गिरफ्तार होने की उम्मीद थी, लेकिन ऐसा नहीं है। सरणी में मान 1, 0, 0 शामिल होंगे।

सही कोड है:

 int arr[3] = {1, 1, 1}; 

इस तरह की उलझन गिरफ्तारी = {0} निर्माण के साथ समानता के कारण हो सकती है, जो पूरे सरणी को शून्य में बदल देती है।

यदि आपकी परियोजना में समान डिज़ाइन सक्रिय रूप से उपयोग किए जाते हैं, तो आप इस निदान को अक्षम कर सकते हैं।

यह भी कोड की दृश्यता की उपेक्षा करने के लिए अनुशंसित नहीं है।

उदाहरण के लिए, रंग मान एन्कोडिंग के लिए कोड निम्नानुसार लिखा गया है:

 int White[3] = { 0xff, 0xff, 0xff }; int Black[3] = { 0x00 }; int Green[3] = { 0x00, 0xff }; 

अंतर्निहित आरंभ के लिए धन्यवाद, सभी रंग सही तरीके से सेट किए गए हैं, लेकिन कोड को अधिक स्पष्ट रूप से लिखना बेहतर है:

 int White[3] = { 0xff, 0xff, 0xff }; int Black[3] = { 0x00, 0x00, 0x00 }; int Green[3] = { 0x00, 0xff, 0x00 }; 

malloc

आगे पढ़ने से पहले, मैं आपसे लेख की सामग्री को ताज़ा करने के लिए कहता हूं " यह जानना महत्वपूर्ण है कि मॉलोक फ़ंक्शन क्या लौटा है "। इस लेख ने बहुत चर्चा और आलोचना उत्पन्न की है। यहाँ कुछ चर्चाएँ हैं: reddit.com/r/cpp , reddit.com/r/C_Programming , habr.com । कभी-कभी वे मुझे मेल में अब इस लेख के बारे में लिखते हैं।

लेख की आलोचना पाठकों ने निम्नलिखित बिंदुओं पर की है:

1. यदि मॉलॉक ने नल को वापस कर दिया , तो यह तुरंत कार्यक्रम से बाहर निकलने से बेहतर है कि आईएफएस का एक गुच्छा लिखें और स्मृति की कमी को किसी तरह से संभालने की कोशिश करें, जिसके कारण कार्यक्रम को निष्पादित करना अक्सर असंभव होता है।

मैंने मेमोरी से बाहर चलने के परिणामों से निपटने के लिए आखिरी तक कॉल नहीं किया था, त्रुटि को अधिक से अधिक फेंक दिया। यदि किसी एप्लिकेशन को बिना किसी चेतावनी के बंद करने की अनुमति है, तो ऐसा ही हो। ऐसा करने के लिए, मॉलॉक के तुरंत बाद या xmalloc (अगले पैराग्राफ देखें) का उपयोग करके केवल एक चेक की आवश्यकता है।

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

2. समाधान के बारे में बात नहीं की गई, जिसमें बाद के सत्यापन के साथ मेमोरी को आवंटित करने या मौजूदा कार्यों का उपयोग करने के लिए फ़ंक्शन-रैपर शामिल हैं, जैसे कि xwalloc ।

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

Xmalloc फ़ंक्शन C मानक लाइब्रेरी का हिस्सा नहीं है (देखें " xmalloc और malloc के बीच अंतर क्या है? ")। हालांकि, इस फ़ंक्शन को अन्य पुस्तकालयों में घोषित किया जा सकता है, उदाहरण के लिए, जीएनयू बर्तनों के पुस्तकालय ( जीएनयू लिब्रीटी ) में।

फ़ंक्शन का सार यह है कि यदि मेमोरी आवंटन विफल हो जाता है तो प्रोग्राम समाप्त हो जाता है। इस फ़ंक्शन का कार्यान्वयन इस तरह दिखाई दे सकता है:

 void* xmalloc(size_t s) { void* p = malloc(s); if (!p) { fprintf (stderr, "fatal: out of memory (xmalloc(%zu)).\n", s); exit(EXIT_FAILURE); } return p; } 

तदनुसार, मॉलॉक के बजाय हर जगह xmalloc फ़ंक्शन को कॉल करके , आप यह सुनिश्चित कर सकते हैं कि प्रोग्राम में अशक्त व्यवहार के किसी भी उपयोग के कारण अपरिभाषित व्यवहार नहीं होगा।

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

3. अधिकांश टिप्पणियां इस प्रकार थीं: "व्यवहार में, मल्लोक कभी भी पूर्ण नहीं लौटता है ।"

सौभाग्य से, मैं अकेला नहीं समझता कि यह गलत दृष्टिकोण है। मुझे वास्तव में मेरे समर्थन में यह टिप्पणी पसंद आई:

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

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

केवल एक चीज जो महत्वपूर्ण है वह यह है कि पुस्तकालयों, डेटाबेसों आदि के डेवलपर्स ऐसा नहीं करते हैं।

पुस्तकालय और जिम्मेदार कोड डेवलपर्स के लिए एक कॉल

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

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

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

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

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

इस प्रकार, लाइब्रेरी के पास कार्य करने के लिए लाइब्रेरी के पास केवल एक सही विकल्प है। आपको IMMEDIATELY की जाँच करने की आवश्यकता है कि फ़ंक्शन वापस आ गया है, और यदि यह NULL है, तो त्रुटि स्थिति वापस करें।

संबंधित लिंक

1. OOM हैंडलिंग ।
2. पूर्ण बिंदुओं के साथ मज़ा: भाग 1 , भाग 2 ।
3. प्रत्येक सी प्रोग्रामर को अपरिभाषित व्यवहार के बारे में क्या जानना चाहिए: भाग 1 , भाग 2 , भाग 3 ।

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