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

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

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

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

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

memset

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

HDHITTESTINFO hhti = {}; 

लेकिन निम्नलिखित तरीके से लिखने के लिए:

 HDHITTESTINFO hhti = { 0 }; 

कारण:

1. {} की तुलना में, कोड पढ़ते समय निर्माण {0} नोटिस करना आसान होता है।
2. {} की तुलना में निर्माण {0} अधिक सहज ज्ञान युक्त है। जिसका अर्थ है, 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 (en)। कभी-कभी पाठक इस लेख के बारे में मुझे ई-मेल करते हैं।

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

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

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

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

2. एक समाधान का कोई विवरण नहीं है जो कि एक चेक के साथ मेमोरी आवंटित करने या पहले से मौजूद कार्यों का उपयोग करने के लिए आवरण कार्यों को लिखने में निहित है, जैसे कि xmalloc ।

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

Xmalloc functionis मानक 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