सी और सी ++ में खुद को पैर में कैसे गोली मारना है। हाइकु ओएस कुकबुक

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

परिचय

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

अब विश्लेषण करना बहुत सरल है। यहाँ परियोजना के निर्माण और विश्लेषण के लिए सभी आदेशों की सूची दी गई है:

cd /opt git clone https://review.haiku-os.org/buildtools git clone https://review.haiku-os.org/haiku cd ./haiku mkdir generated.x86_64; cd generated.x86_64 ../configure --distro-compatibility official -j12 \ --build-cross-tools x86_64 ../../buildtools cd ../../buildtools/jam make all cd /opt/haiku/generated.x86_64 pvs-studio-analyzer trace -- /opt/buildtools/jam/bin.linuxx86/jam \ -q -j1 @nightly-anyboot pvs-studio-analyzer analyze -l /mnt/svn/PVS-Studio.lic -r /opt/haiku \ -C x86_64-unknown-haiku-gcc -o /opt/haiku/haiku.log -j12 

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

Uninitialized चर

V614 Uninitialized चर 'rval' का उपयोग किया गया। fetch.c 1727

 int auto_fetch(int argc, char *argv[]) { volatile int argpos; int rval; // <= argpos = 0; if (sigsetjmp(toplevel, 1)) { if (connected) disconnect(0, NULL); if (rval > 0) // <= rval = argpos + 1; return (rval); } .... } 

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

V614 Uninitialized पॉइंटर 'रेस' का इस्तेमाल किया। आदेश २ commands.c३

 struct addrinfo { int ai_flags; int ai_family; int ai_socktype; int ai_protocol; socklen_t ai_addrlen; char *ai_canonname; struct sockaddr *ai_addr; struct addrinfo *ai_next; }; static int sourceroute(struct addrinfo *ai, char *arg, char **cpp, int *lenp, int *protop, int *optp) { static char buf[1024 + ALIGNBYTES]; char *cp, *cp2, *lsrp, *ep; struct sockaddr_in *_sin; #ifdef INET6 struct sockaddr_in6 *sin6; struct ip6_rthdr *rth; #endif struct addrinfo hints, *res; // <= int error; char c; if (cpp == NULL || lenp == NULL) return -1; if (*cpp != NULL) { switch (res->ai_family) { // <= case AF_INET: if (*lenp < 7) return -1; break; .... } } .... } 

यहाँ uninitialized वैरिएबल का उपयोग करने का एक समान मामला है, सिवाय इसके कि res एक uninitialized पॉइंटर है जो यहाँ होता है।

स्थानीय चर 'सामान्यीकृत' के लिए V506 सूचक इस चर के दायरे से बाहर संग्रहीत किया जाता है। ऐसा पॉइंटर अवैध हो जाएगा। TextView.cpp 5596

 void BTextView::_ApplyStyleRange(...., const BFont* font, ....) { if (font != NULL) { BFont normalized = *font; _NormalizeFont(&normalized); font = &normalized; } .... fStyles->SetStyleRange(fromOffset, toOffset, fText->Length(), mode, font, color); } 

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

V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचेयर .pp 27

 int8 BUnicodeChar::Type(uint32 c) { BUnicodeChar(); return u_charType(c); } 

C ++ प्रोग्रामर्स के बीच एक बहुत ही सामान्य गलती है कि क्लास फिल्ड को इनिशियलाइज़ / न्युलाइज़ करने के लिए कंस्ट्रक्टर के कॉल को माना जाता है। इस स्थिति में, वर्ग फ़ील्ड का संशोधन नहीं होता है, लेकिन इस वर्ग की एक नई अनाम वस्तु बनाई जाती है और फिर तुरंत नष्ट हो जाती है। दुर्भाग्य से, परियोजना में ऐसे बहुत सारे स्थान हैं:

• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार। सीपी 37
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर। 49 49
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचेयर .pp 58
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर। सीपी 67
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर .pp 77
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनीकोडक्रॉप। 89
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर। सीपी 103
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनीकोडक्रॉप। 115
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार। सीपीसी 126
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर .pp 142
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचेयर। 152 152
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडेकर। सीपीयू 163
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनीकोडक्रॉप। 186
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार .Cpp 196
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार .Cpp 206
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार। 214
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार। 222
• V603 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'यह-> बुउनिकोडेकर :: बुउनिकोडेचर (....)' का उपयोग किया जाना चाहिए। यूनिकोडचार। सीपीयू 230

V670 ized fInternal ’सदस्य को आरंभीकृत करने के लिए अनआर्गेनाइज्ड क्लास मेंबर 'fPatternHandler' का उपयोग किया जाता है। याद रखें कि सदस्यों को एक वर्ग के अंदर उनकी घोषणाओं के क्रम में आरंभीकृत किया जाता है। पेंटर.कंप 184

 Painter::Painter() : fInternal(fPatternHandler), .... fPatternHandler(), .... { .... }; class Painter { .... private: mutable PainterAggInterface fInternal; // line 336 bool fSubpixelPrecise : 1; bool fValidClipping : 1; bool fDrawingText : 1; bool fAttached : 1; bool fIdentityTransform : 1; Transformable fTransform; float fPenSize; const BRegion* fClippingRegion; drawing_mode fDrawingMode; source_alpha fAlphaSrcMode; alpha_function fAlphaFncMode; cap_mode fLineCapMode; join_mode fLineJoinMode; float fMiterLimit; PatternHandler fPatternHandler; // line 355 mutable AGGTextRenderer fTextRenderer; }; 

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

संदेहास्पद #define

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। subr_gtaskqueue.c 191

 #define TQ_LOCK(tq) \ do { \ if ((tq)->tq_spin) \ mtx_lock_spin(&(tq)->tq_mutex); \ else \ mtx_lock(&(tq)->tq_mutex); \ } while (0) #define TQ_ASSERT_LOCKED(tq) mtx_assert(&(tq)->tq_mutex, MA_OWNED) #define TQ_UNLOCK(tq) \ do { \ if ((tq)->tq_spin) \ mtx_unlock_spin(&(tq)->tq_mutex); \ else \ mtx_unlock(&(tq)->tq_mutex); \ } while (0) void grouptask_block(struct grouptask *grouptask) { .... TQ_LOCK(queue); gtask->ta_flags |= TASK_NOENQUEUE; gtaskqueue_drain_locked(queue, gtask); TQ_UNLOCK(queue); } 

यह कोड स्निपेट तब तक संदेहास्पद नहीं दिखता जब तक आप प्रीप्रोसेसर परिणाम को नहीं देखते:

 void grouptask_block(struct grouptask *grouptask) { .... do { if ((queue)->tq_spin) mtx_lock(&(queue)->tq_mutex); else mtx_lock(&(queue)->tq_mutex); } while (0); gtask->ta_flags |= 0x4; gtaskqueue_drain_locked(queue, gtask); do { if ((queue)->tq_spin) mtx_unlock(&(queue)->tq_mutex); else mtx_unlock(&(queue)->tq_mutex); } while (0); } 

विश्लेषक वास्तव में सही है - अगर और अन्य शाखाएं समान हैं। लेकिन mtx_lock_spin और mtx_unlock_spin फ़ंक्शन कहाँ हैं? मैक्रोज़ TQ_LOCK , TQ_UNLOCK और grouptask_block फ़ंक्शन एक फ़ाइल में लगभग एक दूसरे के बगल में घोषित किए जाते हैं, लेकिन फिर भी यहां एक प्रतिस्थापन हुआ।

फ़ाइलों के माध्यम से खोज केवल म्यूटेक्स में हुई। निम्न सामग्री के साथ:

 /* on FreeBSD these are different functions */ #define mtx_lock_spin(x) mtx_lock(x) #define mtx_unlock_spin(x) mtx_unlock(x) 

प्रोजेक्ट डेवलपर्स को यह देखना चाहिए कि ऐसा प्रतिस्थापन सही है या नहीं। मैंने लिनक्स में इस परियोजना की जाँच की और इस तरह की जगह मुझे संदेहास्पद लगी।

मुक्त समारोह के साथ त्रुटियाँ

V575 null पॉइंटर को 'फ्री' फंक्शन में पास किया गया है। पहले तर्क का निरीक्षण करें। setmime.cpp 727

 void MimeType::_PurgeProperties() { fShort.Truncate(0); fLong.Truncate(0); fPrefApp.Truncate(0); fPrefAppSig.Truncate(0); fSniffRule.Truncate(0); delete fSmallIcon; fSmallIcon = NULL; delete fBigIcon; fBigIcon = NULL; fVectorIcon = NULL; // <= free(fVectorIcon); // <= fExtensions.clear(); fAttributes.clear(); } 

आप नि: शुल्क फ़ंक्शन में नल पॉइंटर पास कर सकते हैं, लेकिन ऐसा उपयोग निश्चित रूप से संदिग्ध है। इस प्रकार, विश्लेषक को कोड की मिश्रित लाइनें मिलीं। सबसे पहले, कोड लेखक को fVectorIcon पॉइंटर द्वारा मेमोरी जारी करनी थी , उसके बाद ही NULL असाइन करें।

V575 null पॉइंटर को 'फ्री' फंक्शन में पास किया गया है। पहले तर्क का निरीक्षण करें। Driver_settings.cpp 461

 static settings_handle * load_driver_settings_from_file(int file, const char *driverName) { .... handle = new_settings(text, driverName); if (handle != NULL) { // everything went fine! return handle; } free(handle); // <= .... } 

यह नि: शुल्क फ़ंक्शन के लिए एक अशक्त सूचक को पारित करने का एक और उदाहरण है। इस लाइन को हटाया जा सकता है, क्योंकि पॉइंटर को सफलतापूर्वक प्राप्त करने के बाद फ़ंक्शन बाहर निकल जाता है।

V575 null पॉइंटर को 'फ्री' फंक्शन में पास किया गया है। पहले तर्क का निरीक्षण करें। PackageFileHeapWriter.cpp 166

 void* _GetBuffer() { .... void* buffer = malloc(fBufferSize); if (buffer == NULL && !fBuffers.AddItem(buffer)) { free(buffer); throw std::bad_alloc(); } return buffer; } 

किसी ने यहाँ एक त्रुटि की। || ऑपरेटर का उपयोग && के बजाय किया जाना है। केवल इस मामले में std :: bad_alloc () अपवाद को फेंक दिया जाएगा यदि स्मृति आबंटन ( Malloc फ़ंक्शन का उपयोग कर) विफल रहा।

डिलीट ऑपरेटर के साथ त्रुटियां

V611 स्मृति को 'नए टी []' ऑपरेटर के उपयोग से आवंटित किया गया था लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। शायद 'डिलीट [] fMsg;' का उपयोग करना बेहतर है। Err.cpp 65

 class Err { public: .... private: char *fMsg; ssize_t fPos; }; void Err::Unset() { delete fMsg; // <= fMsg = __null; fPos = -1; } void Err::SetMsg(const char *msg) { if (fMsg) { delete fMsg; // <= fMsg = __null; } if (msg) { fMsg = new(std::nothrow) char[strlen(msg)+1]; // <= if (fMsg) strcpy(fMsg, msg); } } 

FMsg पॉइंटर का उपयोग वर्णों की एक सरणी के लिए मेमोरी आवंटित करने के लिए किया जाता है। डिलीट ऑपरेटर का उपयोग डिलीट [] के बजाय मेमोरी को रिलीज़ करने के लिए किया जाता है।

V611 मेमोरी को 'नए' ऑपरेटर के उपयोग से आवंटित किया गया था, लेकिन 'मुफ्त' फ़ंक्शन का उपयोग करके जारी किया गया था। 'रैपरपूल' वेरिएबल के पीछे ऑपरेशन लॉजिक्स का निरीक्षण करने पर विचार करें। vm_page.cpp 3080

 status_t vm_page_write_modified_page_range(....) { .... PageWriteWrapper* wrapperPool = new(malloc_flags(allocationFlags)) PageWriteWrapper[maxPages + 1]; PageWriteWrapper** wrappers = new(malloc_flags(allocationFlags)) PageWriteWrapper*[maxPages]; if (wrapperPool == NULL || wrappers == NULL) { free(wrapperPool); // <= free(wrappers); // <= wrapperPool = stackWrappersPool; wrappers = stackWrappers; maxPages = 1; } .... } 

यहां malloc_flags एक ऐसा कार्य है, जिसे malloc कहते हैं। फिर प्लेसमेंट-नया यहां ऑब्जेक्ट का निर्माण करता है। PageWriteWrapper वर्ग को निम्नलिखित तरीके से लागू किया गया है:

 class PageWriteWrapper { public: PageWriteWrapper(); ~PageWriteWrapper(); void SetTo(vm_page* page); bool Done(status_t result); private: vm_page* fPage; struct VMCache* fCache; bool fIsActive; }; PageWriteWrapper::PageWriteWrapper() : fIsActive(false) { } PageWriteWrapper::~PageWriteWrapper() { if (fIsActive) panic("page write wrapper going out of scope but isn't completed"); } 

मेमोरी को मुक्त करने के लिए नि: शुल्क फ़ंक्शन के उपयोग के कारण इस क्लासवॉटर के ऑब्जेक्ट को नष्ट नहीं किया जाता है।

V611 स्मृति को 'नए टी []' ऑपरेटर के उपयोग से आवंटित किया गया था लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। संभवतः 'डिलीट [] fOutBuffer?' का उपयोग करना बेहतर है। जाँच लाइनें: 26, 45. PCL6Rasterizer.h 26

 class PCL6Rasterizer : public Rasterizer { public: .... ~PCL6Rasterizer() { delete fOutBuffer; fOutBuffer = NULL; } .... virtual void InitializeBuffer() { fOutBuffer = new uchar[fOutBufferSize]; } private: uchar* fOutBuffer; int fOutBufferSize; }; 

डिलीट ऑपरेटर को हटाने के बजाय [] का उपयोग करना एक सामान्य त्रुटि है । कक्षा लिखते समय गलती करना सबसे आसान है, क्योंकि विध्वंसक कोड अक्सर मेमोरी स्थानों से दूर होता है। यहाँ, प्रोग्रामर गलत तरीके से नष्ट कर देता है मेमोरी को fOutBuffer पॉइंटर द्वारा विध्वंसक में जमा करता है।

V772 शून्य पॉइंटर के लिए 'डिलीट' ऑपरेटर को कॉल करने से अपरिभाषित व्यवहार होगा। हैशटेबल। सीपीसी 207

 void Hashtable::MakeEmpty(int8 keyMode,int8 valueMode) { .... for (entry = fTable[index]; entry; entry = next) { switch (keyMode) { case HASH_EMPTY_DELETE: // TODO: destructors are not called! delete (void*)entry->key; break; case HASH_EMPTY_FREE: free((void*)entry->key); break; } switch (valueMode) { case HASH_EMPTY_DELETE: // TODO: destructors are not called! delete entry->value; break; case HASH_EMPTY_FREE: free(entry->value); break; } next = entry->next; delete entry; } .... } 

डिलीट / डिलीट [] और मुफ्त के बीच एक गलत विकल्प के अलावा, आप एक अपरिवर्तनीय व्यवहार में भी चल सकते हैं जब एक पॉइंटर को void प्रकार (शून्य *) से मेमोरी को खाली करने की कोशिश की जाती है।

वापसी मूल्य के बिना कार्य

V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। रेफरेंसेबल। 228

 BReference& operator=(const BReference<const Type>& other) { fReference = other.fReference; } 

एक अतिभारित असाइनमेंट ऑपरेटर के पास वापसी मान का अभाव होता है। इस मामले में, ऑपरेटर एक यादृच्छिक मान लौटाएगा, जिससे अजीब त्रुटियां हो सकती हैं।

यहाँ इस वर्ग के अन्य कोड अंशों में समान मुद्दे हैं:

• V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। रेफरेंसेबल। 233
• V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। रेफर करने योग्य। 239

V591 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। main.c 1010

 void errx(int, const char *, ...) ; char * getoptionvalue(const char *name) { struct option *c; if (name == NULL) errx(1, "getoptionvalue() invoked with NULL name"); c = getoption(name); if (c != NULL) return (c->value); errx(1, "getoptionvalue() invoked with unknown option '%s'", name); /* NOTREACHED */ } 

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

अपवादों को संभालना

V596 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: ParseException (FOO) को फेंक दें; प्रतिक्रिया .कंपनी 659

 size_t Response::ExtractNumber(BDataIO& stream) { BString string = ExtractString(stream); const char* end; size_t number = strtoul(string.String(), (char**)&end, 10); if (end == NULL || end[0] != '\0') ParseException("Invalid number!"); return number; } 

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

V1022 एक अपवाद सूचक द्वारा फेंका गया था। इसके बजाय मूल्य द्वारा फेंकने पर विचार करें। gensyscallinfos.cpp 316

 int main(int argc, char** argv) { try { return Main().Run(argc, argv); } catch (Exception& exception) { // <= fprintf(stderr, "%s\n", exception.what()); return 1; } } int Run(int argc, char** argv) { .... _ParseSyscalls(argv[1]); .... } void _ParseSyscalls(const char* filename) { ifstream file(filename, ifstream::in); if (!file.is_open()) throw new IOException(string("Failed to open '") + filename + "'."); // <= .... } 

विश्लेषक ने सूचक द्वारा फेंके गए IOException अपवाद का पता लगाया। एक पॉइंटर को फेंकने से तथ्य यह होता है कि अपवाद नहीं पकड़ा जाएगा। इसलिए अपवाद को अंततः संदर्भ द्वारा पकड़ा गया है। इसके अलावा, एक पॉइंटर का उपयोग कैचिंग पक्ष को हटाए गए ऑपरेटर को कॉल करने के लिए बाध्य ऑब्जेक्ट को नष्ट करने के लिए मजबूर करता है, जो कि नहीं किया गया था।

मुद्दों के साथ कोड के अन्य टुकड़े:

• V1022 एक अपवाद सूचक द्वारा फेंका गया था। इसके बजाय मूल्य द्वारा फेंकने पर विचार करें। gensyscallinfos.cpp 347
• V1022 एक अपवाद सूचक द्वारा फेंका गया था। इसके बजाय मूल्य द्वारा फेंकने पर विचार करें। gensyscallinfos.cpp 413

औपचारिक सुरक्षा

V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'f_key' ऑब्जेक्ट को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। dst_api.c 1018

 #ifndef SAFE_FREE #define SAFE_FREE(a) \ do{if(a != NULL){memset(a,0, sizeof(*a)); free(a); a=NULL;}} while (0) .... #endif DST_KEY * dst_free_key(DST_KEY *f_key) { if (f_key == NULL) return (f_key); if (f_key->dk_func && f_key->dk_func->destroy) f_key->dk_KEY_struct = f_key->dk_func->destroy(f_key->dk_KEY_struct); else { EREPORT(("dst_free_key(): Unknown key alg %d\n", f_key->dk_alg)); } if (f_key->dk_KEY_struct) { free(f_key->dk_KEY_struct); f_key->dk_KEY_struct = NULL; } if (f_key->dk_key_name) SAFE_FREE(f_key->dk_key_name); SAFE_FREE(f_key); return (NULL); } 

विश्लेषक ने संदिग्ध कोड का पता लगाया है, जिसका अर्थ सुरक्षित निजी डेटा समाशोधन है। दुर्भाग्य से, SAFE_FREE मैक्रो, जो मेमसेट , फ्री कॉल और NULL असाइनमेंट में फैलता है, कोड को सुरक्षित नहीं बनाता है, क्योंकि यह संकलक द्वारा सभी को हटा दिया जाता है जब O2 के साथ अनुकूलन किया जाता है।

वैसे, यह कुछ और नहीं बल्कि CWE-14 : कंपाइलर रिमूवल ऑफ़ कोड टू क्लीयर बफ़र्स है।

यहां उन स्थानों की सूची दी गई है, जहां वास्तव में बफ़र्स को साफ़ नहीं किया जाता है:

• V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'एन्कोडेड_ब्लॉक' बफर को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। dst_api.c 446
• V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'key_st' ऑब्जेक्ट को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। dst_api.c 685
• V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'in_buff' बफर को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। dst_api.c 916
• V597 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'सी' ऑब्जेक्ट को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। fs_cache.c 1078

अहस्ताक्षरित चर के साथ तुलना

V547 एक्सप्रेशन 'शेष <0' हमेशा गलत होता है। Unsign प्रकार का मान कभी नहीं होता है <0। DwarfFile.cpp 1947

 status_t DwarfFile::_UnwindCallFrame(....) { .... uint64 remaining = lengthOffset + length - dataReader.Offset(); if (remaining < 0) return B_BAD_DATA; .... } 

विश्लेषक ने नकारात्मक मानों के साथ अहस्ताक्षरित चर की स्पष्ट तुलना की। शायद, किसी को शेष चर की तुलना केवल नल के साथ करनी चाहिए या अतिप्रवाह के लिए चेक लागू करना चाहिए।

V547 अभिव्यक्ति की नींद ((अहस्ताक्षरित) सेकंड) <0 'हमेशा झूठी होती है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Misc.cpp 56

 status_t snooze(bigtime_t amount) { if (amount <= 0) return B_OK; int64 secs = amount / 1000000LL; int64 usecs = amount % 1000000LL; if (secs > 0) { if (sleep((unsigned)secs) < 0) // <= return errno; } if (usecs > 0) { if (usleep((useconds_t)usecs) < 0) return errno; } return B_OK; } 

त्रुटि के मुख्य बिंदु को प्राप्त करने के लिए, चलो नींद और बेकार कार्यों के हस्ताक्षरों को संबोधित करते हैं:

 extern unsigned int sleep (unsigned int __seconds); extern int usleep (__useconds_t __useconds); 

जैसा कि हम देख सकते हैं, स्लीप फ़ंक्शन अहस्ताक्षरित मान लौटाता है और कोड में इसका उपयोग गलत है।

खतरनाक संकेत

V774 मेमोरी जारी होने के बाद 'डिवाइस' पॉइंटर का उपयोग किया गया था। xhci.cpp 1572

 void XHCI::FreeDevice(Device *device) { uint8 slot = fPortSlots[device->HubPort()]; TRACE("FreeDevice() port %d slot %d\n", device->HubPort(), slot); // Delete the device first, so it cleans up its pipes and tells us // what we need to destroy before we tear down our internal state. delete device; DisableSlot(slot); fDcba->baseAddress[slot] = 0; fPortSlots[device->HubPort()] = 0; // <= delete_area(fDevices[slot].trb_area); delete_area(fDevices[slot].input_ctx_area); delete_area(fDevices[slot].device_ctx_area); memset(&fDevices[slot], 0, sizeof(xhci_device)); fDevices[slot].state = XHCI_STATE_DISABLED; } 

डिलीट ऑपरेटर द्वारा एक डिवाइस ऑब्जेक्ट को हटा दिया जाता है। यह FreeDevice फ़ंक्शन के लिए काफी तार्किक है। लेकिन, किसी कारण से, अन्य संसाधनों को जारी करने के लिए, पहले से हटाए गए ऑब्जेक्ट को संबोधित किया जाता है।

ऐसा कोड बेहद खतरनाक है और इसे कई अन्य स्थानों पर भी देखा जा सकता है:

• V774 मेमोरी जारी होने के बाद 'सेल्फ' पॉइंटर का उपयोग किया गया था। TranslatorRoster.cpp 884
• V774 मेमोरी जारी होने के बाद 'स्ट्रिंग' पॉइंटर का उपयोग किया गया था। RemoteView.cpp 1269
• V774 मेमोरी जारी होने के बाद 'bs' पॉइंटर का उपयोग किया गया था। mkntfs.c 4291
• V774 मेमोरी जारी होने के बाद 'bs' पॉइंटर का उपयोग किया गया था। mkntfs.c 4308
• V774 'अल' पॉइंटर का उपयोग मेमोरी के पुनः प्राप्ति के बाद किया गया था। inode.c 1155

V522 नल सूचक 'डेटा' की डेरेफेरिंग हो सकती है। नल पॉइंटर को 'malo_hal_send_helper' फंक्शन में पास किया जाता है। तीसरे तर्क का निरीक्षण करें। चेक लाइनें: 350, 394. if_malohal.c 350

 static int malo_hal_fwload_helper(struct malo_hal *mh, char *helper) { .... /* tell the card we're done and... */ error = malo_hal_send_helper(mh, 0, NULL, 0, MALO_NOWAIT); // <= NULL .... } static int malo_hal_send_helper(struct malo_hal *mh, int bsize, const void *data, size_t dsize, int waitfor) { mh->mh_cmdbuf[0] = htole16(MALO_HOSTCMD_CODE_DNLD); mh->mh_cmdbuf[1] = htole16(bsize); memcpy(&mh->mh_cmdbuf[4], data , dsize); // <= data .... } 

Interprocedural विश्लेषण से यह पता चला कि जब NULL फ़ंक्शन में जाता है और इस तरह के मान के साथ डेटा पॉइंटर अंततः मेमसीपी फ़ंक्शन में dereferenced जाता है।

V773 'inputFileFile' पॉइंटर जारी किए बिना फ़ंक्शन को बाहर किया गया था। एक स्मृति रिसाव संभव है। command_recompress.cpp 119

 int command_recompress(int argc, const char* const* argv) { .... BFile* inputFileFile = new BFile; error = inputFileFile->SetTo(inputPackageFileName, O_RDONLY); if (error != B_OK) { fprintf(stderr, "Error: Failed to open input file \"%s\": %s\n", inputPackageFileName, strerror(error)); return 1; } inputFile = inputFileFile; .... } 

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

V595 nullptr के खिलाफ सत्यापित होने से पहले 'fReply' पॉइंटर का उपयोग किया गया था। जाँच करें लाइनें: 49, 52.

 RPC::CallbackReply* ReplyBuilder::Reply() { fReply->Stream().InsertUInt(fStatusPosition, _HaikuErrorToNFS4(fStatus)); fReply->Stream().InsertUInt(fOpCountPosition, fOpCount); if (fReply == NULL || fReply->Stream().Error() == B_OK) return fReply; else return NULL; } 

यह जाँच करने से पहले बिंदुओं को रोकने के लिए एक बहुत ही सामान्य गलती है। V595 डायग्नोस्टिक लगभग हमेशा एक परियोजना में चेतावनी की संख्या में रहता है। इस कोड के टुकड़े में fReply पॉइंटर का खतरनाक उपयोग शामिल है।

V595 nullptr के खिलाफ सत्यापित होने से पहले 'mq' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 782, 786. oce_queue.c 782

 static void oce_mq_free(struct oce_mq *mq) { POCE_SOFTC sc = (POCE_SOFTC) mq->parent; struct oce_mbx mbx; struct mbx_destroy_common_mq *fwcmd; if (!mq) return; .... } 

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

विविध

V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 101

 static void dump_acpi_namespace(acpi_ns_device_info *device, char *root, int indenting) { char output[320]; char tabs[255] = ""; .... strlcat(tabs, "|--- ", sizeof(tabs)); .... while (....) { uint32 type = device->acpi->get_object_type(result); snprintf(output, sizeof(output), "%s%s", tabs, result + depth); switch(type) { case ACPI_TYPE_INTEGER: strncat(output, " INTEGER", sizeof(output)); break; case ACPI_TYPE_STRING: strncat(output, " STRING", sizeof(output)); break; .... } .... } .... } 

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

यहाँ तार के साथ खतरनाक स्थानों की पूरी सूची है:

• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 104
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 107
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 110
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 113
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 118
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 119
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 120
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 123
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 126
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 129
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 132
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 135
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 138
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 141
• V645 'strncat' फंक्शन कॉल से 'आउटपुट' बफर ओवरफ्लो हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। NamespaceDump.cpp 144
• V645 'strncat' फ़ंक्शन कॉल 'features_string' बफर अतिप्रवाह हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। VirtioDevice.cpp 283
• V645 'strncat' फ़ंक्शन कॉल 'features_string' बफर अतिप्रवाह हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। VirtioDevice.cpp 284
• V645 'strncat' फ़ंक्शन कॉल 'features_string' बफर अतिप्रवाह हो सकता है। सीमा में बफ़र का आकार नहीं होना चाहिए, लेकिन कई वर्ण इसे पकड़ सकते हैं। VirtioDevice.cpp 285

V792 ऑपरेटर के दाईं ओर स्थित 'SetDecoratorSettings' फ़ंक्शन | वाम ऑपरेंड के मूल्य की परवाह किए बिना कहा जाएगा। शायद, '' का उपयोग करना बेहतर है। DesktopListener.cpp 324

 class DesktopListener : public DoublyLinkedListLinkImpl<DesktopListener> { public: .... virtual bool SetDecoratorSettings(Window* window, const BMessage& settings) = 0; .... }; bool DesktopObservable::SetDecoratorSettings(Window* window, const BMessage& settings) { if (fWeAreInvoking) return false; InvokeGuard invokeGuard(fWeAreInvoking); bool changed = false; for (DesktopListener* listener = fDesktopListenerList.First(); listener != NULL; listener = fDesktopListenerList.GetNext(listener)) changed = changed | listener->SetDecoratorSettings(window, settings); return changed; } 

सबसे अधिक संभावना है, '|' और '||' संचालकों को ठग लिया गया। यह त्रुटि SetDecoratorSettings फ़ंक्शन के अनावश्यक कॉल की ओर जाता है।

V627 अभिव्यक्ति का निरीक्षण करने पर विचार करें। Sizeof () का तर्क वह मैक्रो है जो एक संख्या तक फैलता है। device.c 72

 #define PCI_line_size 0x0c /* (1 byte) cache line size in 32 bit words */ static status_t wb840_open(const char* name, uint32 flags, void** cookie) { .... data->wb_cachesize = gPci->read_pci_config(data->pciInfo->bus, data->pciInfo->device, data->pciInfo->function, PCI_line_size, sizeof(PCI_line_size)) & 0xff; .... } 

आकार ऑपरेटर को 0x0c मान पास करना संदेहास्पद लगता है। शायद, लेखक को किसी ऑब्जेक्ट के आकार का मूल्यांकन करना चाहिए, उदाहरण के लिए, डेटा ।

V562 18: 0x12 == IsProfessionalSpdif () के मान के साथ बूल टाइप मान की तुलना करना अजीब है। CEchoGals_mixer.cpp 533

 typedef bool BOOL; virtual BOOL IsProfessionalSpdif() { ... } #define ECHOSTATUS_DSP_DEAD 0x12 ECHOSTATUS CEchoGals::ProcessMixerFunction(....) { .... if ( ECHOSTATUS_DSP_DEAD == IsProfessionalSpdif() ) // <= { Status = ECHOSTATUS_DSP_DEAD; } else { pMixerFunction->Data.bProfSpdif = IsProfessionalSpdif(); } .... } 

IsProfessionalSpdif फ़ंक्शन बूल प्रकार मान लौटाता है। ऐसा करने में, फ़ंक्शन के परिणाम की तुलना स्थिति में 0x12 संख्या के साथ की जाती है।

निष्कर्ष

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

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

क्या आप हाइकु को आजमाना चाहते हैं और आपके पास सवाल हैं? हाइकु डेवलपर्स आपको टेलीग्राम-चैनल पर आमंत्रित करते हैं।