सी ++ बिल्डर पुस्तकालयों में त्रुटियां मिलीं

हमने Embarcadero C ++ बिल्डर XE3 के साथ शामिल हेडर फ़ाइलों की जाँच की। वास्तव में, इसका मतलब केवल इनलाइन कार्यों की एक छोटी संख्या की जांच करना है। तदनुसार, बहुत कम संदिग्ध स्थान पाए गए, लेकिन एक छोटे नोट के लिए पर्याप्त।

परिचय

हम नियमित रूप से खुली परियोजनाओं की जांच करते हैं , साथ ही साथ बाकी सब कुछ भी जांच सकते हैं। उदाहरण के लिए, हमने उन पुस्तकालयों की जाँच की जो विज़ुअल C ++ 2012 का हिस्सा हैं। परिणाम एक नोट था: " त्रुटियाँ Visual C ++ 2012 पुस्तकालयों में पाई गई थीं ।"

Visual C ++ वितरण में पुस्तकालयों के लिए स्रोत कोड शामिल है। C ++ बिल्डर के साथ स्थिति बदतर है। केवल हेडर फाइलें हैं। इसलिए, केवल कुछ इनलाइन फ़ंक्शन की जांच करना संभव था। फिर भी, मैं कुछ दिलचस्प खोजने में कामयाब रहा। कोड के संबंधित अनुभागों पर विचार करें।

अलर्ट के साथ काम करें

  #pragma चेतावनी (अक्षम करें: 4115)
 # अलग करना <objbase.h>
 #pragma चेतावनी (डिफ़ॉल्ट: 4115) 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V665 संभवतः, इस संदर्भ में '#pragma चेतावनी (डिफ़ॉल्ट: X)' का उपयोग गलत है। इसके बजाय '#Pagma चेतावनी (पुश / पॉप)' का उपयोग किया जाना चाहिए। चेक लाइन: 16, 18. आईगिड.एच 18

चेतावनी आउटपुट मोड को डिफ़ॉल्ट पर सेट करना अच्छा नहीं है। सही स्थिति पहले की स्थिति को बचाने और फिर बहाल करने की होगी। ऐसा करने के लिए, "#pragma चेतावनी (पुश [, n])" और "#pragma चेतावनी (पॉप)" का उपयोग करें।

मैक्रो विफल

  #define SET_VTYPE_AND_VARREF (प्रकार, वैल) \
   यह-> vt = VT_ ## प्रकार |  VT_BYREF;  \
   V_ ## प्रकार ## REF (यह) = वैल;

 TVariantT & ऑपरेटर = (सिस्टम :: मुद्रा * src)
 {
   साफ़ ();
   अगर (src)
     SET_VTYPE_AND_VARREF (CY,
       reinterpret_cast <tagCY *> (((src-> Val)));
   वापसी * ​​यह;
 } 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V640 कोड का परिचालन तर्क इसके प्रारूपण के अनुरूप नहीं है। दूसरा कथन हमेशा निष्पादित किया जाएगा। यह संभव है कि घुंघराले कोष्ठक गायब हैं। यूक्लेक्श 1781

मैक्रो SET_VTYPE_AND_VARREF खराब लिखा गया है। इसकी सामग्री को ब्रेसिज़ {} द्वारा तैयार नहीं किया गया है। नतीजतन, शर्त "if (src)" केवल मैक्रो की पहली पंक्ति पर लागू होगी।

अपरिभाषित व्यवहार

  #define _BITS_BYTE 8
 टेम्पलेट <वर्ग _Uint,
     _उंट _Ax,
     _Uint _Cx,
     _Uint _Mx>
     वर्ग रैखिक_ संकेतात्मक
 {
   स्थिर _CONST_DATA int _Nw =
     (_BITS_BYTE * sizeof (_Uint) + 31) / 32;

   शून्य बीज (seed_seq & _Seq)
   {
     _उंट _Arr [3 + _Nw];
     ....
     int _Lsh = _BITS_BYTE * sizeof (_Uint);
     ....

     for (int _Idx = _Nw; 0 <--_ Idx;)
       _Arr [3 + _Idx - 1] = |
         _Arr [3 + _Idx] << _Lsh;
     ....
   }
 } 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V610 इंस्टेंटिअरी लीनियर_केंग्रेंशियल <बिना बताए लंबा, 40014, 0, 2147483563>: अपरिभाषित व्यवहार। शिफ्ट ऑपरेटर की जाँच करें <<। दायाँ ऑपरेंड '_Lsh' प्रमोटेड लेफ्ट ऑपरेंड के बिट्स में लंबाई के बराबर या उससे अधिक होता है। यादृच्छिक 738

इस फ़ंक्शन में, वैरिएबल '_Lsh' मान 32 ले जाएगा। आप 32-बिट प्रकार को 31 से अधिक बिट्स द्वारा स्थानांतरित नहीं कर सकते। मानक से अंश: सही संचालन नकारात्मक होने पर व्यवहार अपरिभाषित होता है, या पदोन्नत किए गए बाएं ऑपरेंड के बिट्स में लंबाई से अधिक या उसके बराबर होता है।

इसके अलावा, DXVABitMask मैक्रो को खतरनाक तरीके से बनाया गया था:

  #define DXVABitMask (__ n) (~ ((~ 0) << __n)) 

मानक से संबंधित रेखा को उद्धृत करने के लिए: अन्यथा, यदि E1 में एक हस्ताक्षरित प्रकार और गैर-नकारात्मक मूल्य है, और E1 * 2 ^ E2 परिणाम प्रकार में प्रतिनिधित्व करने योग्य है, तो यह परिणामी मूल्य है; अन्यथा, व्यवहार अपरिभाषित है।

इस मैक्रो के कारण, PVS-Studio कई चेतावनियाँ प्रदर्शित करता है। एक उदाहरण:

V610 अपरिभाषित व्यवहार। शिफ्ट ऑपरेटर की जाँच करें <<। बायाँ ऑपरेंड '(~ 0)' निगेटिव है। dxva.h 1080

आप लेख में बदलाव और अपरिभाषित व्यवहार के बारे में और अधिक पढ़ सकते हैं: बिना कांटे को जाने, पानी में नहीं उतरें। भाग तीन

नए ऑपरेटर के व्यवहार में अप्रत्याशित बदलाव।

ऐसे कुछ स्थान थे, जहां 'नए' ऑपरेटर को कॉल करने के बाद, यह जांचा जाता है कि सूचक NULL नहीं है। अब इसका कोई मतलब नहीं है और यह हानिकारक भी है। स्मृति आबंटन त्रुटि के मामले में, 'नया' ऑपरेटर एक अपवाद std :: bad_alloc फेंकता है।

आप ऑपरेटर को 'नया' कह सकते हैं, जो अपवाद नहीं फेंकता है। C ++ बिल्डर के पास इसके लिए एक विशेष मैक्रो भी है:

  #define NEW_NOTHROW (_bytes) नया (nothrow) BYTE [_bytes] 

हालांकि, स्पष्ट रूप से हर जगह स्मृति के आवंटन के साथ आदेश को बहाल करना संभव नहीं था। मैं कुछ उदाहरण दूंगा:

  इनलाइन शून्य _bstr_t :: असाइन करें (BSTR s) फेंक (_com_error)
 {
   अगर (m_Data! = NULL) {
     m_Data-> असाइन (एस); 
   } 
   और {
     m_Data = new Data_t (s, TRUE);
     अगर (m_Data == NULL) {
       _com_issue_error (E_OUTOFMEMORY);
     }
   }
 } 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V668 नल के खिलाफ 'm_Data' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि मेमोरी को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। comutil.h 454

लाइन "_com_issue_error (E_OUTOFMEMORY);" कभी अमल नहीं किया गया। त्रुटि के मामले में, एक अपवाद std :: bad_alloc () फेंक दिया जाएगा।

  स्थिर इनलाइन BYTE * __ CorHlprNewThrows (size_t बाइट्स)
 {
   BYTE * pbMemory = नया BYTE [बाइट्स];
   अगर (pbMemory == NULL)
     __CorHlprThrowOOM ();
   वापसी pbMemory;
 } 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V668 नल के खिलाफ 'pbMemory' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। corhlpr.h 56

  टेम्पलेट <वर्ग TYPE, कक्षा ARG_TYPE>
 शून्य CDXArray <TYPE, ARG_TYPE> :: SetSize (int nNewSize, int nGrowBy)
 {
   ....
   TYPE * pNewData = (TYPE *) नया BYTE [nNewMax * sizeof (TYPE)];

   // ओह, यह दुर्घटनाग्रस्त होने से बेहतर है
   अगर (pNewData == NULL)
     वापसी;
   ....
 } 

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक ​​संदेश:

V668 नल के खिलाफ 'pNewData' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि मेमोरी को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। dxtmpl.h 338

बाकी कोड के टुकड़े समान हैं, और उन्हें उद्धृत करने का कोई मतलब नहीं है। मैं खुद को केवल नैदानिक ​​संदेशों तक सीमित करूंगा:

• V668 नल के खिलाफ 'पी' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। d3dx10math.inl 1008
• V668 नल के खिलाफ 'पी' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। dxtmpl.h 123
• V668 नल के खिलाफ 'pNewData' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि मेमोरी को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। dxtmpl.h 395
• V668 नल के खिलाफ 'm_pHashTable' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। dxtmpl.h 1126
• V668 नल के खिलाफ 'newBrush' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि 'new' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbrush.h 44
• V668 नल के खिलाफ 'रेटिमेज' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbrush.h 374
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbrush.h 615
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbrush.h 645
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdipluspath.h 1196
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdipluspath.h 1231
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdipluspath.h 1372
• V668 नल के खिलाफ 'आर्ग्स' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdipluspath.h 1405
• V668 नल के खिलाफ 'newLineCap' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdipluslinecaps.h 153
• V668 नल के खिलाफ 'nativeRegions' पॉइंटर के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusgraphics.h 1415
• V668 'newRegion' पॉइंटर को अशक्त करने के परीक्षण में कोई समझदारी नहीं है, क्योंकि 'new' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusregion.h 89
• V668 नल के खिलाफ 'nativeFamilyList' पॉइंटर के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusfontcollection.h 57
• V668 नल के खिलाफ 'newImage' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि 'new' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbitmap.h 334
• V668 नल के खिलाफ 'बिटमैप' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbitmap.h 819
• V668 नल के खिलाफ 'बिटमैप' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। gdiplusbitmap.h 862
• V668 नल के खिलाफ 'm_pData' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। spcollec.h 266
• V668 नल के खिलाफ 'pNewData' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि मेमोरी को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। spcollec.h 325

और यह केवल इनलाइन फ़ंक्शन है! कल्पना करें कि * .cpp फ़ाइलों में क्या हो रहा है। :)

टिप्पणी

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

निष्कर्ष

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

1. पीवीएस-स्टूडियो टूल का विवरण । आप पूरी तरह कार्यात्मक परीक्षण संस्करण डाउनलोड कर सकते हैं।
2. एंड्रे कार्पोव। C ++ बिल्डर, 64-बिट अनुप्रयोगों और Viva64 पुनर्जागरण की विधानसभा ।
3. हमारा ट्विटर @ कोड_अनलिसिस । हम C / C ++ के विषय पर कई दिलचस्प लिंक प्रकाशित करते हैं।
4. पीवीएस-स्टूडियो क्या कर सकता है। पीवीएस-स्टूडियो डेवलपर्स द्वारा ओपन सोर्स प्रोजेक्ट्स में त्रुटियों का पता लगाकर स्थैतिक विश्लेषण किया गया ।