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

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

परिचय

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

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

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 वैरिएबल का उपयोग करने का एक समान मामला, केवल यहाँ 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 फ़ंक्शन एक ही फ़ाइल में और लगभग एक साथ घोषित किए जाते हैं , हालांकि, कहीं-कहीं एक प्रतिस्थापन था।

निम्न सामग्री के साथ केवल mutex.h फ़ाइलों की सामग्री पर एक खोज:

 /* 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 () यदि यह संभव नहीं है तो मॉल फ़ंक्शन का उपयोग करके मेमोरी आवंटित करना।

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

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; } .... } 

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

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

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 अनुकूलन के दौरान संकलक द्वारा हटा दिया जाता है।

वैसे, यह सीडब्ल्यूई -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; .... } 

पीवीएस-स्टूडियो मेमोरी लीक का पता लगा सकता है । 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 पॉइंटर को dereferenced किया गया है। परियोजना में कई समान स्थान हैं। कुछ स्थानों पर, पॉइंटर्स का उपयोग करना और जांचना एक दूसरे से बहुत दूर है, इसलिए लेख में दो उदाहरण शामिल किए गए हैं। बाकी डेवलपर्स को पूर्ण विश्लेषक रिपोर्ट में देख पाएंगे।

विविध त्रुटियाँ

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' फ़ंक्शन कॉल 'आउटपुट' बफर अतिप्रवाह हो सकता है। The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 107
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 110
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 113
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 118
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 119
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 120
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 123
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 126
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 129
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 132
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 135
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 138
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 141
• V645 The 'strncat' function call could lead to the 'output' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. NamespaceDump.cpp 144
• V645 The 'strncat' function call could lead to the 'features_string' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. VirtioDevice.cpp 283
• V645 The 'strncat' function call could lead to the 'features_string' buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold. 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 संख्या के साथ तुलना किया जाता है ।

निष्कर्ष

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

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

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: Svyatoslav Razmyslov। सी और सी ++ में पैर में खुद को कैसे गोली मारनी है। हाइकु ओएस कुकबुक