C और C ++ के लिए बेस्ट कॉपी-पेस्ट एल्गोरिदम। हाइकु ओएस रेसिपी संग्रह

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

परिचय

हाइकू व्यक्तिगत कंप्यूटरों के लिए एक स्वतंत्र, खुला स्रोत ऑपरेटिंग सिस्टम है। वर्तमान में, डेवलपर्स का एक अंतरराष्ट्रीय समूह सिस्टम के घटकों पर सक्रिय रूप से काम कर रहा है। विकास के अंतिम महत्वपूर्ण विकास में लिबरऑफिस को ऑपरेटिंग सिस्टम में पोर्ट करना और आर 2 बीटा 1 के पहले बीटा संस्करण को जारी करना था।

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

1. हाइकु ऑपरेटिंग सिस्टम (BeOS परिवार) की जाँच करना। भाग 1
2. हाइकु ऑपरेटिंग सिस्टम (BeOS परिवार) की जाँच करना। भाग 2 ;
3. सी और सी ++ में खुद को पैर में कैसे गोली मारना है। हाइकु ओएस रेसिपी संग्रह

नवीनतम कोड विश्लेषण की एक विशेषता लिनक्स के लिए पीवीएस-स्टूडियो के आधिकारिक संस्करण का उपयोग करने की क्षमता है। 2015 में, यह वहाँ नहीं था, साथ ही त्रुटियों को देखने के लिए एक सुविधाजनक रिपोर्ट भी थी। अब हम डेवलपर्स को एक सुविधाजनक प्रारूप में पूरी रिपोर्ट भेजेंगे।

शैली के क्लासिक्स

V501 बाईं और '-' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: (addr_t) b - (addr_t) b BitmapManager.cpp 51

int compare_app_pointer(const ServerApp* a, const ServerApp* b) { return (addr_t)b - (addr_t)b; } 

अपने जीवन में हर प्रोग्रामर को a और b , x और y , i और j ... आदि चरों को मिलाना चाहिए।

V501 बाईं और 'के दाईं ओर समान उप-अभिव्यक्तियाँ हैं' || ऑपरेटर: इनपुट == __null || इनपुट == __null MediaClient.cpp 182

 status_t BMediaClient::Unbind(BMediaInput* input, BMediaOutput* output) { CALLED(); if (input == NULL || input == NULL) return B_ERROR; if (input->fOwner != this || output->fOwner != this) return B_ERROR; input->fBind = NULL; output->fBind = NULL; return B_OK; } 

इस स्थिति में, एक ही इनपुट पॉइंटर को दो बार जांचा जाता है, और आउटपुट पॉइंटर अनियंत्रित रहता है, जिससे नल पॉइंटर को निष्क्रिय किया जा सकता है।

सही किया गया कोड:

 if (input == NULL || output == NULL) return B_ERROR; 

V583 '?:' संचालक, चाहे उसकी सशर्त अभिव्यक्ति की परवाह किए बिना, हमेशा एक और एक ही मूल्य देता है: 500000। usb_modeswitch.cpp 361

 static status_t my_transfer_data(....) { .... do { bigtime_t timeout = directionIn ? 500000 : 500000; result = acquire_sem_etc(device->notify, 1, B_RELATIVE_TIMEOUT, timeout); .... } while (result == B_INTERRUPTED); .... } 

टर्नररी ऑपरेटर ने अपना अर्थ खो दिया जब प्रोग्रामर ने एक गलती की और दो समान रिटर्न मान लिखे - 500000 ।

V519 'm_kindex1' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 40, 41. agg_trans_double_path.cpp 41

 trans_double_path::trans_double_path() : m_kindex1(0.0), m_kindex2(0.0), m_base_length(0.0), m_base_height(1.0), m_status1(initial), m_status2(initial), m_preserve_x_scale(true) { } void trans_double_path::reset() { m_src_vertices1.remove_all(); m_src_vertices2.remove_all(); m_kindex1 = 0.0; m_kindex1 = 0.0; m_status1 = initial; m_status2 = initial; } 

रीसेट फ़ंक्शन में एक त्रुटि हुई: m_kindex2 चर के सूचकांक में एक टाइपो। इस चर का मान रीसेट नहीं किया जाएगा, जो अन्य कोड टुकड़ों के निष्पादन को प्रभावित करने की संभावना है।

V501 बाएं और '>' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: fg [order_type :: R]> fg [क्रम_type :: R] agg_span_image_filter-rgba.h 898

 typedef Source source_type; typedef typename source_type::color_type color_type; typedef typename source_type::order_type order_type; void generate(color_type* span, int x, int y, unsigned len) { .... if(fg[0] < 0) fg[0] = 0; if(fg[1] < 0) fg[1] = 0; if(fg[2] < 0) fg[2] = 0; if(fg[3] < 0) fg[3] = 0; if(fg[order_type::A] > base_mask) fg[order_type::A] = base_mask; if(fg[order_type::R] > fg[order_type::R])fg[order_type::R] = fg[order_type::R]; if(fg[order_type::G] > fg[order_type::G])fg[order_type::G] = fg[order_type::G]; if(fg[order_type::B] > fg[order_type::B])fg[order_type::B] = fg[order_type::B]; .... } 

आखिरी पंक्तियों में समान चर की तुलना और तुरंत समान चर की असाइनमेंट है। मैं यह नहीं मान सकता कि यहाँ क्या सोचा गया था। बस टुकड़े को संदिग्ध के रूप में चिह्नित करें।

V570 'wPipeIndex' वेरिएबल को ही असाइन किया गया है। CEchoGals_transport.cpp 244

 ECHOSTATUS CEchoGals::CloseAudio (....) { .... wPipeIndex = wPipeIndex; m_ProcessId[ wPipeIndex ] = NULL; m_Pipes[ wPipeIndex ].wInterleave = 0; .... } 

WPipeIndex वैरिएबल अपने स्वयं के मूल्य के लिए आरंभिक है। सबसे अधिक संभावना है, एक टाइपो बनाया गया था।

संकेत के साथ त्रुटियाँ

V522 अशक्त सूचक 'currentInterface' की Dereferencing हो सकती है। Device.cpp 258

 Device::Device(....) : .... { .... usb_interface_info* currentInterface = NULL; // <= uint32 descriptorStart = sizeof(usb_configuration_descriptor); while (descriptorStart < actualLength) { switch (configData[descriptorStart + 1]) { .... case USB_DESCRIPTOR_ENDPOINT: { .... if (currentInterface == NULL) // <= break; currentInterface->endpoint_count++; .... } .... case USB_DESCRIPTOR_ENDPOINT_COMPANION: { usb_endpoint_descriptor* desc = currentInterface // <= ->endpoint[currentInterface->endpoint_count - 1].descr; .... } .... } 

वर्तमानइंटरफेस पॉइंटर को शुरू में शून्य से शुरू किया जाता है और फिर स्विच स्टेटमेंट शाखा में प्रवेश करते समय जांच की जाती है, लेकिन सभी मामलों में नहीं। विश्लेषक चेतावनी देता है कि जब USB_DESCRIPTOR_ENDPOINT_COMPANION लेबल पर जा रहा है, तो अशक्त सूचक को निष्क्रिय करना संभव है।

V522 नल पॉइंटर की निर्देशिका 'निर्देशिका' हो सकती है। PathMonitor.cpp 1465

 bool PathHandler::_EntryCreated(....) { .... Directory* directory = directoryNode->ToDirectory(); if (directory == NULL) { // We're out of sync with reality. if (!dryRun) { if (Entry* nodeEntry = directory->FirstNodeEntry()) { .... } } return false; } .... } 

मेरा मानना ​​है कि अशक्त मान के साथ डायरेक्टरी पॉइंटर की तुलना करने में गलती हुई और स्थिति विपरीत होनी चाहिए। वर्तमान कार्यान्वयन में, यदि ड्राईरन चर गलत है , तो निर्देशिका अशक्त सूचक को निष्क्रिय कर दिया जाएगा।

V522 शून्य पॉइंटर की 'इनपुट' जगह ले सकता है। MediaRecorder.cpp 343

 void GetInput(media_input* input); const media_input& BMediaRecorder::MediaInput() const { CALLED(); media_input* input = NULL; fNode->GetInput(input); return *input; } 

इनपुट पॉइंटर को शून्य पर आरंभीकृत किया जाता है और उस मूल्य पर रहता है, क्योंकि GetInput फ़ंक्शन में, सूचक नहीं बदलता है। BMediaRecorder क्लास के अन्य तरीके उदाहरण के लिए अलग-अलग लिखते हैं:

 status_t BMediaRecorder::_Connect(....) { .... // Find our Node's free input media_input ourInput; fNode->GetInput(&ourInput); // <= .... } 

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

V522 अशक्त सूचक 'mustFree' की Dereferencing हो सकती है। RequestUnflattener.cpp 35

 status_t Reader::Read(int32 size, void** buffer, bool* mustFree) { if (size < 0 || !buffer || mustFree) // <= return B_BAD_VALUE; if (size == 0) { *buffer = NULL; *mustFree = false; // <= return B_OK; } .... } 

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

 if (size < 0 || !buffer || !mustFree) // <= return B_BAD_VALUE; 

V757 यह संभव है कि 'डायनेमिक_कास्ट' का उपयोग करके टाइप रूपांतरण के बाद एक गलत चर की तुलना नल्टर के साथ की जाती है। लाइनों की जाँच करें: 474, 476

 void checkStructure(Disk &disk) { .... Inode* missing = gMissing.Get(run); dir = dynamic_cast<Directory *>(missing); if (missing == NULL) { .... } .... } 

अनुपलब्ध सूचक के बजाय, आपको रूपांतरण के बाद dir सूचक की जांच करनी चाहिए। वैसे, C # प्रोग्रामर अक्सर एक समान गलती करते हैं। यह एक बार फिर साबित करता है कि उपयोग की गई भाषा से कुछ त्रुटियां स्वतंत्र हैं।

कोड में कुछ और समान स्थान:

• V757 यह संभव है कि 'डायनेमिक_कास्ट' का उपयोग करके टाइप रूपांतरण के बाद एक गलत चर की तुलना नल्टर के साथ की जाती है। चेक लाइन्स: 355, 357. एक्सपेंडेओमेनुआर.सीपीपी 355
• V757 यह संभव है कि 'डायनेमिक_कास्ट' का उपयोग करके टाइप रूपांतरण के बाद एक गलत चर की तुलना नल्टर के साथ की जाती है। जाँच लाइनें: 600, 601. ValControl.cpp 600

सूचकांक त्रुटियां

V557 ऐरे ओवररन संभव है। 'BT_SCO' सूचकांक सरणी बाउंड से परे इंगित कर रहा है। h2upper.cpp 75

 struct bt_usb_dev { .... struct list nbuffersTx[(1 + 1 + 0 + 0)]; // <= [0..1] .... } typedef enum { BT_COMMAND = 0, BT_EVENT, BT_ACL, BT_SCO, // <= 3 BT_ESCO, HCI_NUM_PACKET_TYPES } bt_packet_t; void sched_tx_processing(bt_usb_dev* bdev) { .... if (!list_is_empty(&bdev->nbuffersTx[BT_SCO])) { // <= fail // TODO to be implemented } .... } 

Bdev-> nbuffersTx सरणी में केवल दो तत्व होते हैं, जबकि कोड में इसे निरंतर BT_SCO द्वारा एक्सेस किया जाता है, जिसका मान 3. होता है। सरणी के सीमाओं से परे एक गारंटीकृत निकास होता है।

V557 ऐरे ओवररन संभव है। 'Ieee80211_send_setup' फ़ंक्शन '16' को संसाधित करता है। चौथे तर्क का निरीक्षण करें। चेक लाइनें: 842, 911. ieee80211_output.c 842

 struct ieee80211_node { .... struct ieee80211_tx_ampdu ni_tx_ampdu[16]; // <= [0..15] .... }; #define IEEE80211_NONQOS_TID 16 int ieee80211_mgmt_output(....) { .... ieee80211_send_setup(ni, m, IEEE80211_FC0_TYPE_MGT | type, IEEE80211_NONQOS_TID, // <= 16 vap->iv_myaddr, ni->ni_macaddr, ni->ni_bssid); .... } void ieee80211_send_setup( struct ieee80211_node *ni, struct mbuf *m, int type, int tid, // <= 16 ....) { .... tap = &ni->ni_tx_ampdu[tid]; // <= 16 .... } 

एक और तरीका सरणी से बाहर है। इस मामले में, सिर्फ एक आइटम। Interprocedural विश्लेषण ने ऐसी स्थिति की पहचान करने में मदद की जहां सरणी ni-> ni_tx_ampdu , 16 तत्वों से मिलकर, अनुक्रमणिका 16 पर पहुंची थी। C और C ++ में, सरणी अनुक्रमण खरोंच से किया जाता है।

V781 'वेक्टर' वैरिएबल के मान का उपयोग करने के बाद जाँच की जाती है। शायद प्रोग्राम लॉजिक में कोई गलती है। चेक लाइन: 802, 805. oce_if.c 802

 #define OCE_MAX_EQ 32 typedef struct oce_softc { .... OCE_INTR_INFO intrs[OCE_MAX_EQ]; .... } OCE_SOFTC, *POCE_SOFTC; static int oce_alloc_intr(POCE_SOFTC sc, int vector, void (*isr) (void *arg, int pending)) { POCE_INTR_INFO ii = &sc->intrs[vector]; int rc = 0, rr; if (vector >= OCE_MAX_EQ) return (EINVAL); .... } 

एनालाइज़र ने एक अमान्य इंडेक्स पर sc-> इंट्रस एरे को कॉल का पता लगाया (एरे की सीमा से परे जाकर)। इसका कारण गलत कोड ऑर्डर है। यहां, सरणी को पहले एक्सेस किया जाता है, और फिर यह देखने के लिए एक चेक बनाया जाता है कि क्या इंडेक्स वैल्यू वैध है।

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

V519 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 199, 200. nvme_ctrlr.c 200

 static void nvme_ctrlr_set_intel_supported_features(struct nvme_ctrlr *ctrlr) { bool *supported_feature = ctrlr->feature_supported; supported_feature[NVME_INTEL_FEAT_MAX_LBA] = true; supported_feature[NVME_INTEL_FEAT_MAX_LBA] = true; supported_feature[NVME_INTEL_FEAT_NATIVE_MAX_LBA] = true; supported_feature[NVME_INTEL_FEAT_POWER_GOVERNOR_SETTING] = true; supported_feature[NVME_INTEL_FEAT_SMBUS_ADDRESS] = true; supported_feature[NVME_INTEL_FEAT_LED_PATTERN] = true; supported_feature[NVME_INTEL_FEAT_RESET_TIMED_WORKLOAD_COUNTERS] = true; supported_feature[NVME_INTEL_FEAT_LATENCY_TRACKING] = true; } 

अनुक्रमणिका NVME_INTEL_FEAT_MAX_LBA के साथ सरणी तत्व को समान मान दिया गया है। सौभाग्य से, इस फ़ंक्शन में सभी संभावित स्थिरांक का प्रतिनिधित्व किया जाता है, और कोड केवल कॉपी-पेस्ट प्रोग्रामिंग का परिणाम है। लेकिन इस तरह से गलतियाँ करने की संभावना बहुत अधिक है।

V519 'copyPath [लेन]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 92, 93. कर्नेल_मू। सीपी 93

 int UserlandFS::KernelEmu::new_path(const char *path, char **copy) { .... // append a dot, if desired if (appendDot) { copiedPath[len] = '.'; copiedPath[len] = '\0'; } .... } 

और यहां डेवलपर नकल के साथ भाग्यशाली नहीं था। प्रतीक "डॉट" को एक निश्चित लाइन में जोड़ा जाता है और तुरंत एक टर्मिनल शून्य द्वारा अधिलेखित कर दिया जाता है। सबसे अधिक संभावना है, कोड के लेखक ने स्ट्रिंग की प्रतिलिपि बनाई और सूचकांक में वृद्धि करना भूल गया।

अजीब स्थिति है

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइन: 1407, 1410। FindPanel.cpp 1407

 void FindPanel::BuildAttrQuery(BQuery* query, bool &dynamicDate) const { .... case B_BOOL_TYPE: { uint32 value; if (strcasecmp(textControl->Text(), "true") == 0) { value = 1; } else if (strcasecmp(textControl->Text(), "true") == 0) { value = 1; } else value = (uint32)atoi(textControl->Text()); value %= 2; query->PushUInt32(value); break; } .... } 

कोड को तुरंत कॉपी करने से दो त्रुटियां हुईं। सशर्त अभिव्यक्ति समान हैं। सबसे अधिक संभावना है, उनमें से एक में "सच" के बजाय स्ट्रिंग "झूठे" के साथ तुलना होनी चाहिए। अगला, उस शाखा में जो मूल्य को "झूठा" बनाती है, आपको मूल्य मान को 1 से 0 तक बदलना चाहिए। एल्गोरिथ्म मानता है कि सत्य या असत्य के अलावा किसी भी अन्य मूल्यों को एटोई फ़ंक्शन का उपयोग करके संख्या में परिवर्तित किया जाएगा, लेकिन एक त्रुटि के कारण, पाठ को "झूठा" भी मिल जाएगा।

V547 अभिव्यक्ति 'त्रुटि == ((int) 0)' हमेशा सत्य होती है। Directory.cpp 688

 int32 BDirectory::CountEntries() { status_t error = Rewind(); if (error != B_OK) return error; int32 count = 0; BPrivate::Storage::LongDirEntry entry; while (error == B_OK) { if (GetNextDirents(&entry, sizeof(entry), 1) != 1) break; if (strcmp(entry.d_name, ".") != 0 && strcmp(entry.d_name, "..") != 0) count++; } Rewind(); return (error == B_OK ? count : error); } 

विश्लेषक ने पाया कि त्रुटि चर का मान हमेशा B_OK होगा । सबसे अधिक संभावना है, जबकि लूप में इस चर का एक संशोधन याद किया गया था।

V564 '' और 'ऑपरेटर को बूल प्रकार मान पर लागू किया जाता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। strtod.c 545

 static int lo0bits(ULong *y) { int k; ULong x = *y; .... if (!(x & 1)) { k++; x >>= 1; if (!x & 1) // <= return 32; } *y = x; return k; } 

सबसे अधिक संभावना है, अंतिम सशर्त अभिव्यक्ति में वे कोष्ठक लगाना भूल गए, जैसा कि ऊपर की स्थितियों में है। संभवतः, वहाँ भी, नकारात्मक परिचालक कोष्ठक के बाहर होना चाहिए:

 if (!(x & 1)) // <= return 32; 

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। पोस व्यू.कॉप 5851

 bool BPoseView::AttributeChanged(const BMessage* message) { .... result = poseModel->OpenNode(); if (result == B_OK || result != B_BUSY) break; .... } 

यह स्पष्ट नहीं है, लेकिन स्थिति का परिणाम B_OK के मूल्य पर निर्भर नहीं करता है। इस प्रकार, इसे सरल बनाया जा सकता है:

 If (result != B_BUSY) break; 

परिणाम चर के मूल्यों के लिए एक सत्य तालिका बनाकर इसे आसानी से सत्यापित किया जाता है। यदि आपको विशेष रूप से B_OK और B_BUSY के अलावा अन्य मानों पर विचार करने की आवश्यकता है, तो कोड को अलग तरीके से फिर से लिखा जाना चाहिए।

दो और समान स्थितियां:

• V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। Tracker.cpp 1714
• V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। if_ipw.c 1871

V590 'argc == 0' का निरीक्षण करने पर विचार करें argc! = 2 'अभिव्यक्ति। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। cmds.c 2667

 void unsetoption(int argc, char *argv[]) { .... if (argc == 0 || argc != 2) { fprintf(ttyout, "usage: %s option\n", argv[0]); return; } .... } 

शायद यह सबसे सरल उदाहरण है जो V590 नैदानिक ​​के संचालन को दर्शाता है। यदि कोई तर्क पारित नहीं होता है, या उनमें से दो नहीं हैं, तो कार्यक्रम का विवरण प्रदर्शित करना आवश्यक है। जाहिर है, शून्य सहित दो के अलावा कोई भी मान, शर्त को पूरा नहीं करेगा। इसलिए, स्थिति को आसानी से निम्नलिखित के लिए सरल बनाया जा सकता है:

 if (argc != 2) { fprintf(ttyout, "usage: %s option\n", argv[0]); return; } 

V590 '* ptr ==' का निरीक्षण करने पर विचार करें; && * ptr! = '\ 0' 'अभिव्यक्ति। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। पीसीसी 316

 ULONG parse_expression(char *str) { .... ptr = skipwhite(ptr); while (*ptr == SEMI_COLON && *ptr != '\0') { ptr++; if (*ptr == '\0') continue; val = assignment_expr(&ptr); } .... } 

इस उदाहरण में, तार्किक ऑपरेटर बदल गया है, लेकिन तर्क समान है। यहाँ, जबकि लूप की स्थिति केवल इस बात पर निर्भर करती है कि चरित्र SEMI_COLON के बराबर है या नहीं।

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। writembr.cpp 99

 int main(int argc, char** argv) { .... string choice; getline(cin, choice, '\n'); if (choice == "no" || choice == "" || choice != "yes") { cerr << "MBR was NOT written" << endl; fs.close(); return B_ERROR; } .... } 

इस उदाहरण में पहले से ही तीन शर्तें हैं। यह जांचना भी आसान हो सकता है कि उपयोगकर्ता ने "हाँ" चुना है या नहीं:

 if (choice != "yes") { cerr << "MBR was NOT written" << endl; fs.close(); return B_ERROR; } 

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

V530 फ़ंक्शन 'आरंभ' के वापसी मूल्य का उपयोग करने की आवश्यकता है। IMAPFolder.cpp 414

 void IMAPFolder::RegisterPendingBodies(...., const BMessenger* replyTo) { .... IMAP::MessageUIDList::const_iterator iterator = uids.begin(); for (; iterator != uids.end(); iterator++) { if (replyTo != NULL) fPendingBodies[*iterator].push_back(*replyTo); else fPendingBodies[*iterator].begin(); // <= } } 

विश्लेषक ने शुरुआत () पुनरावृत्ति के लिए एक अर्थहीन कॉल का पता लगाया । मैं अनुमान नहीं लगा सकता कि कोड को कैसे ठीक किया जाए। डेवलपर को इस जगह पर ध्यान देना चाहिए।

V609 को शून्य से विभाजित करें। डेनोमिनेटर रेंज [0..64]। UiUtils.cpp 544

 static int32 GetSIMDFormatByteSize(uint32 format) { switch (format) { case SIMD_RENDER_FORMAT_INT8: return sizeof(char); case SIMD_RENDER_FORMAT_INT16: return sizeof(int16); case SIMD_RENDER_FORMAT_INT32: return sizeof(int32); case SIMD_RENDER_FORMAT_INT64: return sizeof(int64); case SIMD_RENDER_FORMAT_FLOAT: return sizeof(float); case SIMD_RENDER_FORMAT_DOUBLE: return sizeof(double); } return 0; } const BString& UiUtils::FormatSIMDValue(const BVariant& value, uint32 bitSize, uint32 format, BString& _output) { _output.SetTo("{"); char* data = (char*)value.ToPointer(); uint32 count = bitSize / (GetSIMDFormatByteSize(format) * 8); // <= .... } 

GetSIMDFormatByteSize फ़ंक्शन वास्तव में डिफ़ॉल्ट मान के रूप में 0 देता है, जो संभावित रूप से शून्य से विभाजन की ओर ले जा सकता है।

V654 लूप की स्थिति 'विशिष्टता! = अनुक्रम' हमेशा झूठी होती है। pthread_key.cpp 55

 static void* get_key_value(pthread_thread* thread, uint32 key, int32 sequence) { pthread_key_data& keyData = thread->specific[key]; int32 specificSequence; void* value; do { specificSequence = keyData.sequence; if (specificSequence != sequence) return NULL; value = keyData.value; } while (specificSequence != sequence); keyData.value = NULL; return value; } 

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

V672 यहाँ नया 'पाथ' वैरिएबल बनाने की शायद कोई आवश्यकता नहीं है। फ़ंक्शन के तर्कों में से एक के पास एक ही नाम है और यह तर्क एक संदर्भ है। जाँच लाइनें: 348, 429. अनुवाद 4pp.29

 status_t Translator::FindPath(...., TypeList &path, double &pathQuality) { .... TypeList path; double quality; if (FindPath(&formats[j], stream, typesSeen, path, quality) == B_OK) { if (bestQuality < quality * formatQuality) { bestQuality = quality * formatQuality; bestPath.SetTo(path); bestPath.Add(formats[j].type); status = B_OK; } } .... } 

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

V705 यह संभव है कि 'और' ब्लॉक को भुला दिया गया या टिप्पणी नहीं की गई, इस प्रकार कार्यक्रम के ऑपरेशन लॉजिक्स को बदल दिया गया। HostnameView.cpp 109

 status_t HostnameView::_LoadHostname() { BString fHostnameString; char hostname[MAXHOSTNAMELEN]; if (gethostname(hostname, MAXHOSTNAMELEN) == 0) { fHostnameString.SetTo(hostname, MAXHOSTNAMELEN); fHostname->SetText(fHostnameString); return B_OK; } else return B_ERROR; } 

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

V763 पैरामीटर 'मेनू' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। वीडियो। 6 648

 bool video_mode_hook(Menu *menu, MenuItem *item) { video_mode *mode = NULL; menu = item->Submenu(); item = menu->FindMarked(); .... } 

ऐसे कई मामले थे जहां फ़ंक्शन के तर्क समारोह के प्रवेश द्वार पर तुरंत लिखे जाते हैं। यह व्यवहार अन्य डेवलपर्स के लिए भ्रामक है जो इन समान कार्यों को लागू करते हैं।

संदिग्ध स्थानों की पूरी सूची:

• V763 पैरामीटर 'force_16bit' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ata_adapter.cpp 151
• V763 पैरामीटर 'force_16bit' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ata_adapter.cpp 179
• V763 पैरामीटर 'मेनू' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। video.cpp 264
• V763 पैरामीटर 'लंबाई' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। MailMessage.cpp 677
• V763 पैरामीटर 'प्रविष्टि' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। IconCache.cpp 773
• V763 पैरामीटर 'प्रविष्टि' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। IconCache.cpp 832
• V763 पैरामीटर 'प्रविष्टि' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। IconCache.cpp 864
• V763 पैरामीटर 'रेक' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ErrorLogWindow.cpp 56
• V763 पैरामीटर 'updateRect' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। CalendarMenuWindow.cpp 49
• V763 पैरामीटर 'रेक' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। MemoryView.cpp 165
• V763 पैरामीटर 'रेक' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। TypeEditors.cpp 1124
• V763 पैरामीटर 'ऊँचाई' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। कार्यस्थान। 85pp 857
• V763 पैरामीटर 'चौड़ाई' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। कार्यक्षेत्र। 85pp 856
• V763 पैरामीटर 'फ्रेम' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में हमेशा फिर से लिखा जाता है। SwatchGroup.cpp 48
• V763 पैरामीटर 'फ्रेम' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में हमेशा फिर से लिखा जाता है। PlaylistWindow.cpp 89
• V763 पैरामीटर 'रेक' का उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। विन्यास। 78pp 78
• V763 पैरामीटर 'm' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। mkntfs.c 3917
• V763 पैरामीटर 'rxchainmask' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ar5416_cal.c 463
• V763 पैरामीटर 'c' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। if_iwn.c 6854

निष्कर्ष

हाइकु परियोजना दिलचस्प और दुर्लभ बग का एक स्रोत है। हमने त्रुटि उदाहरणों के हमारे डेटाबेस को फिर से भर दिया और कोड विश्लेषण के दौरान पहचाने गए विश्लेषक में कई समस्याओं को ठीक किया।

यदि आपने लंबे समय तक किसी भी कोड विश्लेषण उपकरण के साथ अपने कोड की जांच नहीं की है, तो वर्णित कुछ आपके कोड में भी है। यदि यह C, C ++, C # या Java में लिखा है, तो कोड की गुणवत्ता को नियंत्रित करने के लिए अपने प्रोजेक्ट में PVS-Studio का उपयोग करें। आप यहां बिना पंजीकरण और एसएमएस के विश्लेषक डाउनलोड कर सकते हैं ।

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



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