C ++ कोड के स्थिर विश्लेषण के लिए उपयोगिताओं का विश्लेषण

निम्नलिखित उपयोगिताओं का विश्लेषण:

• RATS (सुरक्षा के लिए पर्याप्त ऑडिटिंग टूल)
• Cppcheck
• Graudit

लिंक पर क्लिक करके आपको जो कुछ भी चाहिए वह मिल सकता है और हम तुरंत व्यापार में उतर जाएंगे।

टेस्ट 1:

int main() { vector<int> v; v.reserve(2); assert(v.capacity() == 2); v[0]; v[0] = 1; v[1] = 2; cout << v[0] << endl; v.reserve(100); cout << v[0] << endl; return 0; } 

इस कोड का सावधानीपूर्वक अध्ययन करें, आप कितनी समस्याओं की पहचान कर सकते हैं?
बेशक, सभी आवश्यक हेडर शामिल हैं ( आईओस्ट्रीम, वेक्टर, कैसर्ट )।
इस कोड के पेशेवर संस्करणों पर चर्चा करने से पहले, हम स्रोत कोड के स्थैतिक विश्लेषण के लिए प्रसिद्ध उपयोगिताओं का विश्लेषण करेंगे। उपरोक्त उपयोगिताओं का परिणाम निम्न है।

RATS : कुछ भी नहीं
Cppcheck : कुछ भी नहीं
ग्रुदित : कुछ नहीं
g ++ (-Wall झंडे के साथ) : कुछ नहीं

हो सकता है कि पहली नज़र में यह इतना बुरा नहीं है, या इसमें कुछ भी बुरा नहीं है? इसे सटर के साथ मत कहो (अन्य बातों के अलावा, एक उदाहरण उनकी पुस्तक "सी ++ में न्यू कॉम्प्लेक्स प्रॉब्लम। सॉल्यूशंस के साथ 40 नई पहेली उदाहरण" से लिया गया है )।
मुख्य () फ़ंक्शन के शरीर में पहली पंक्ति पर, हम एक वेक्टर v की घोषणा करते हैं जिसमें पूर्णांक होते हैं। फिर हम 2 तत्वों के लिए जगह आरक्षित करते हैं। अगली पंक्ति पर जाने से पहले, C ++ मानक पर एक नज़र डालें। वह हमें वेक्टर :: रिजर्व विधि के बारे में क्या बताती है? (चेतावनी: मुफ्त अनुवाद)
"

 void reserve(size_type n); 

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

जबकि यह पर्याप्त है, चलो आगे बढ़ते हैं। स्ट्रिंग assert (v.capacity () == 2); सबसे अच्छे स्थान पर, पहले स्थान पर आरक्षित () क्षमता वृद्धि की गारंटी देता है और इस मामले में मुखर कोड की एक अतिरिक्त लाइन है (जो "प्रोग्रामर" सम्मिलित करना पसंद करते हैं क्योंकि वे प्रत्येक ऑपरेशन के बाद एस्टर पर विश्वास करते हैं और इसे एक पेशेवर स्वर मानते हैं)। दूसरे, जैसा कि हमने स्वयं मानक से सीखा है, रिज़र्व () दिए गए तर्क की तुलना में कंटेनर की क्षमता को बढ़ा सकता है, इसलिए Satter जोर देता है (v.capacity ()> = 2) । मैं इसे पूरी तरह से हटाने की सलाह देता हूं।
आगे और भी बुरा। " वेक्टर <टी> :: ऑपरेटर [] ऑपरेटर एक सीमा की जांच करने के लिए आवश्यक नहीं है, लेकिन हो सकता है। मानक इस बारे में कुछ नहीं कहते हैं, इसलिए मानक पुस्तकालय के डेवलपर को इस तरह के चेक को जोड़ने और इसके बिना करने का पूरा अधिकार है। " - गटर । सब कुछ का कारण दक्षता है, परीक्षण में कुछ समय लगता है, ऐसे कई चेक को कार्यक्रम के समय के एक महत्वपूर्ण हिस्से की आवश्यकता होगी। लेकिन इसका मतलब यह नहीं है कि आपका प्रभावी कार्यक्रम वासियों के विश्वसनीय कार्यक्रम से बेहतर है। पंक्ति v [0] को बदलने का प्रयास करें ; v.at (0) पर; कार्यक्रम एक अपवाद के साथ उड़ान भरेगा। जो, ज्यादातर मामलों में, विश्वसनीय कोड की आवश्यकता होती है। वेक्टर <T> :: सूचकांक मूल्य पर एक सीमा की जाँच करता है। इस पद्धति का उपयोग करने के लिए एक सख्त सिफारिश, और न केवल स्थितियों में।

लाइन्स v [0] = 1; v [१] = २; काफी अच्छी तरह से काम करते हैं, आप एक उदाहरण को संकलित करके आश्वस्त हो सकते हैं। लेकिन आपको आकार / आकार और रिज़र्व / क्षमता के बीच के अंतर को याद रखना होगा। कंटेनर के अंत में जोड़कर या हटाकर निर्दिष्ट तर्क मान में कंटेनर में तत्वों की संख्या में परिवर्तन करें। हमने मानक से आरक्षित विधि के बारे में सीखा, हम जोड़ते हैं कि यह आंतरिक बफर के आकार को बढ़ाता है ताकि यह निर्दिष्ट संख्या में तत्वों (कम से कम) को समायोजित कर सके। " हम सुरक्षित रूप से ऑपरेटर [] (या विधि पर) का उपयोग केवल उन तत्वों को बदलने के लिए कर सकते हैं जो वास्तव में कंटेनर में निहित हैं, अर्थात, वास्तव में आकार में ध्यान में रखा जाता है। " इसलिए स्थैतिक विश्लेषण उपयोगिताओं भी स्पष्ट नहीं हैं। लेकिन समस्या महत्वपूर्ण है। सटर और कई अन्य पेशेवरों ने अपनी पुस्तकों में अपने पसंदीदा C ++ में कोडिंग में सूक्ष्म बिंदुओं के बारे में लिखा। पहली नज़र में, ऐसा लग सकता है कि भाषा की वाक्य रचना की समस्याओं और ज्ञान को हल करने की क्षमता विकास के लिए पर्याप्त से अधिक है। लेकिन आप और मैं जानते हैं कि हम खुद को बेवकूफ बना रहे हैं, आप में से कितने ने समस्या की पहचान करने के लिए कोड की प्रत्येक पंक्ति पर cout- s डाला? आपमें से कितने लोग उस डिबगिंग को सहन नहीं कर सके जो तीसरे दिन पहले से ही प्रदर्शन कर रही थी? तो, ऐसे लोग हैं जो ऐसी चीजों में निहित नहीं हैं, जिनमें पेशेवर प्रोग्रामिंग कौशल वाले लोग भी शामिल हैं जो आगे जाने के लिए आलसी नहीं हैं और सटर और मायर्स (और कई अन्य) जैसे गुरुओं द्वारा पुस्तकों का अध्ययन करते हैं।

और फिर भी, उदाहरण 1 में, हम अंतिम तार्किक त्रुटि की प्रतीक्षा कर रहे हैं, आपको क्या लगता है कि cout << v [0] आउटपुट ; रिजर्व (100) के बाद? यह सही है, सबसे अच्छा शून्य पर! ध्यान दें कि आरक्षण से पहले हमने v [0] को एक गैर-शून्य मान दिया था। "समस्या" बैकअप फ़ंक्शन में फिर से है।
तो सामान्य मामले में क्या बात है? तथ्य यह है कि मुझे एक उपयोगिता की आवश्यकता है जो आपको बताती है कि v.reserve (2) के मामले में ; v [0] = 1; v.resize (2) का उपयोग करना बेहतर है ; v [0] = 1; या v.reserve (2); v.push_back (1) ! और हमारे द्वारा मानी जाने वाली उपयोगिताओं को चुपचाप शांत किया गया था। मुझे एक उपयोगिता भी चाहिए जो अवैध सीमाओं की जांच करती है, और v [0] के मामले में ; v.at (0) का उपयोग करने की सलाह देते हैं । और हमारी समीक्षा की गई उपयोगिताएं फिर से चुपचाप अच्छी थीं। अत: नाजुक परिस्थितियों में नैतिकता RATS, Cppcheck जैसी उपयोगिताओं पर निर्भर नहीं होती है, और ग्रेगिट पर और भी बहुत कुछ। यहां तक ​​कि चेतावनी के उच्चतम स्तर के साथ एक संकलक को कभी-कभी एक पागल एनकोडर की आंखों के माध्यम से देखा जाना चाहिए।
ठीक है, यह व्यर्थ नहीं है कि उपयोगिताओं आपके शिकंजा पर अपना स्थान लेती हैं, और यह कुछ भी नहीं है कि डेवलपर्स ने इस पर काम किया है।

टेस्ट 2:

आगे बढ़ते हैं, कोड में त्रुटियों की खुराक बढ़ाते हैं। नए prettyFormat फ़ंक्शन के साथ समान कोड पर विचार करें (उदाहरण के लिए फिर से Satter)। उसे नंबर और बफर मिलता है, फिर स्प्रिंट का उपयोग करके उस नंबर को परिणामी बफर में सम्मिलित करता है।

 void prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); } int main() { vector<int> v; v.reserve(2); //.... char buf[5]; prettyFormat(10, buf); return 0; } 

जैसा कि आप देख सकते हैं, prettyFormat जोड़ा गया था , और स्ट्रिंग चार buf [10] । हालाँकि हमें अब पिछले उदाहरण से कोड की आवश्यकता नहीं होगी, लेकिन इसे रहने दें, हो सकता है कि उपयोगिताओं में से कोई कुछ देखेगा? यहाँ परिणाम है:

RATS: ऑन लाइन चार बफ [5]; " उच्च: निश्चित आकार के स्थानीय बफर। अतिरिक्त देखभाल पर ध्यान देना चाहिए कि स्टैक पर आवंटित चरित्र सरणियों को सुरक्षित रूप से उपयोग किया जाता है। वे बफर ओवरफ्लो हमलों के लिए मुख्य लक्ष्य हैं। " चरित्र सरणियों का उपयोग करते समय सावधानी बरतने की सलाह दी जाती है, क्योंकि जब वे सहायक होते हैं। बफर अतिप्रवाह हमलों।
Cppcheck : कुछ भी नहीं
ग्रुदित : कुछ नहीं
g ++ (-Wall विकल्प के साथ) : कुछ भी नहीं

बफर ओवरफ्लो के बारे में बहुत कुछ कहा गया है, इसलिए हम संक्षिप्त होंगे और सिर्फ आलोचना करेंगे। मुझे आभास है कि स्थैतिक विश्लेषण के उपकरण केवल बफर ओवरफ्लो के संभावित मामलों को खोजने के लिए हैं। हालांकि, उनमें से कई ऐसे मामलों में भी चुप हैं (जैसे Cppcheck या Graudit)। मैं संकलक को दोष नहीं देता, उसने मुझे समस्याओं को खोजने से नहीं रोका, लेकिन ज्यादातर मामलों में विशेष रूप से ऐसी चीजों के लिए डिज़ाइन की गई उपयोगिताओं प्यारा चुप हैं। ऐसी स्थितियों में, हमें स्प्रिंट (अच्छी तरह से, अन्य संभावित कार्यों के लिए) विकल्प का उपयोग करने के लिए उपयोगिताओं से चेतावनी और सिफारिशें प्राप्त करने की आवश्यकता है। वैकल्पिक स्थितियों को Satter में पढ़ा जाना चाहिए (हम std :: stringstream, std :: strstream, बढ़ावा :: lexical_cast के बारे में बात कर रहे हैं , हालाँकि उत्तरार्द्ध std :: stringstream पर आधारित है, और अंत में स्निपरफ , जो आपको बफर के आकार को सेट करने की अनुमति देता है, जिससे सुरक्षा सुनिश्चित होती है। बफर अतिप्रवाह से)।

टेस्ट 3:

PrettyFormat फ़ंक्शन के लिए एक अनइंस्टाल्यूटेड पॉइंटर जोड़ें।

 int* prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); int* a; return a; } int main() { ... 

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

आरएटीएस : पिछले परीक्षण के समान ही (हम स्ट्रिंग चार बफ के बारे में बात कर रहे हैं [5];)
Cppcheck : ऑन लाइन int * a; फेंकता (त्रुटि) Uninitialized चर: a।
ठीक है, लेकिन ...
g ++ (-Wall विकल्प के साथ) : फ़ंक्शन में 'int * prettyFormat (int, char *)':
चेतावनी: 'a' का प्रयोग इस फंक्शन में अनइंस्टाल किया जाता है।
कुछ परिचित यह नहीं है? वही चेतावनी जो Cppcheck ने अंततः दी।
आमतौर पर ग्रैडिट चुप है।

टेस्ट 4:

हास्य जोड़ें, इस तरह से prettyFormat फ़ंक्शन बदलें:

 int* prettyFormat(int i, char* buf) { sprintf(buf, "%4d", i); int* a; fopen("filename", "r"); char buf2[5]; strcpy(buf2, buf); return a; } 

फोपेन को जोड़ा गया था, जो खोलता है मुझे नहीं पता कि क्या, एक स्थानीय buf2 बफर जोड़ा गया था, जिसमें buf, जिसे एक तर्क के रूप में प्राप्त किया जाता है, को strcpy का उपयोग करके कॉपी किया जाता है। देखते हैं कौन कितना देता है।

RATS: स्ट्रिंग्स के लिए char buf2 [5]; char buf [10] फिक्स्ड-साइज़ कैरेक्टर बफ़र्स के उपयोग की देखभाल के बारे में वही चेतावनी।
और अंत में: "उच्च: strcpy
यह सुनिश्चित करने के लिए जांचें कि इस फ़ंक्शन कॉल में दिए गए तर्क 2 की प्रतिलिपि नहीं बनेगी
से अधिक डेटा को संभाला जा सकता है, जिसके परिणामस्वरूप बफर अतिप्रवाह होता है। ”
जांचें कि क्या दूसरा तर्क buf2 की तुलना में अधिक डेटा कॉपी करेगा।
बुरा नहीं है, कई स्थितियों में यह मदद करेगा। और आगे चलते हैं।
Cppcheck : (त्रुटि) अनधिकृत चर: a।
कुछ परिचित, पिछले उदाहरण के समान, लेकिन क्षमा करें।
g ++ (-Wall विकल्प के साथ) : पिछले परीक्षण की तरह ही।

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

आपका ध्यान के लिए धन्यवाद!

PS मैं कोड संशोधन ब्लॉग प्रकाशित करना चाहता था, पर्याप्त कर्म नहीं है। नहीं, यह नहीं है कि मैं इस तरह से कर्म बढ़ाना चाहता हूं, बस अगर भीड़ नहीं है - "यहाँ और वहाँ क्यों नहीं ..."।

PPS Habrasociety को बहुत बहुत धन्यवाद - इसे बनाए रखें!