🕺🏽 🍳 🌫️ C और C ++ के लिए बेस्ट कॉपी-पेस्ट एल्गोरिदम। हाइकु ओएस कुकबुक 🖍️ 👩🏻‍🎤 🕸️

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

परिचय

हाइकू व्यक्तिगत कंप्यूटरों के लिए एक मुफ्त खुला स्रोत ऑपरेटिंग सिस्टम है। एक अंतरराष्ट्रीय विकास टीम वर्तमान में सिस्टम के घटकों पर काम कर रही है। OS में पोर्टिंग लिब्रे ऑफिस और पहला R1 Beta 1 रिलीज़ हाल के महत्वपूर्ण विकास सुधारों में से एक है।

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

अंतिम कोड विश्लेषण की विशेषता लिनक्स के लिए पीवीएस-स्टूडियो के आधिकारिक संस्करण का उपयोग करने की क्षमता है। 2015 में न तो लिनक्स के लिए पीवीएस-स्टूडियो, और न ही त्रुटियों को देखने के लिए एक सुविधाजनक रिपोर्ट 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; }

इनपुट पॉइंटर को null द्वारा इनिशियलाइज़ किया जाता है और ऐसे मान के साथ रहता है, क्योंकि पॉइंटर इंप्यूटेंट फ़ंक्शन में पॉइंटर नहीं बदल रहा है। उदाहरण के लिए, 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) { .... } .... }

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

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

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 सरणी में केवल 2 तत्व शामिल हैं, लेकिन इसे 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 ++ के लिए बेस्ट कॉपी-पेस्ट एल्गोरिदम। हाइकु ओएस कुकबुक