बाय-प्रोडक्ट: हम पीवीएस-स्टूडियो का उपयोग करके फायरबर्ड की जांच करते हैं

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

Firebird

फायरबर्ड (FirebirdSQL) - एक कॉम्पैक्ट, क्रॉस-प्लेटफ़ॉर्म, फ्री डेटाबेस मैनेजमेंट सिस्टम (DBMS), लिनक्स, माइक्रोसॉफ्ट विंडोज और यूनिक्स प्लेटफार्मों की एक किस्म पर चल रहा है।

वेबसाइट: http://www.firebirdsql.org/

विकिपीडिया: फायरबर्ड पर विवरण

आइए देखें कि पीवीएस-स्टूडियो का उपयोग करके इस परियोजना के कोड में क्या दिलचस्प पाया जा सकता है।

Uninitialized चर

static const UCHAR* compile(const UCHAR* sdl, sdl_arg* arg) { SLONG n, count, variable, value, sdl_operator; .... switch (op) { .... case isc_sdl_add: sdl_operator = op_add; case isc_sdl_subtract: if (!sdl_operator) sdl_operator = op_subtract; ...... } 

V614 Uninitialized चर 'sdl_operator' का उपयोग किया जाता है। sdl.cpp 404

मुझे ऐसा लगता है कि "केस isc_sdl_add:" और "केस isc_sdl_subtract:" के बीच ऑपरेटर 'ब्रेक' विशेष रूप से गायब है। जब हम तुरंत "केस isc_sdl_subtract:" में आते हैं तो इस मामले पर ध्यान नहीं दिया जाता है। यदि ऐसा होता है, तो 'sdl_operator' वैरिएबल अभी तक आरंभीकृत नहीं किया जाएगा।

इसी तरह की एक और स्थिति। यदि "फ़ील्ड == असत्य" है तो चर 'फील्डनोड' अनइंस्टाल्यूट हो सकता है।

 void blb::move(....) { .... const FieldNode* fieldNode; if (field) { if ((fieldNode = ExprNode::as<FieldNode>(field))) .... } .... const USHORT id = fieldNode->fieldId; .... } 

V614 पोटेंशियल अनइंस्टाल्ड पॉइंटर 'फ़ील्डनोड' का इस्तेमाल किया। blb.cpp 1043

यही कारण है कि अलग-अलग चर को एक ही नाम देने के लिए फ़ंक्शन में यह बुरा है:

 void realign(....) { for (....) { UCHAR* p = buffer + field->fld_offset; .... for (const burp_fld* field = relation->rel_fields; field; field = field->fld_next) { .... UCHAR* p = buffer + FB_ALIGN(p - buffer, sizeof(SSHORT)); ........ } 

V573 Uninitialized चर 'p' का उपयोग किया गया था। वैरिएबल का इस्तेमाल खुद को इनिशियलाइज़ करने के लिए किया जाता था। rest.cpp 17535

दूसरे चर 'p ’को प्रारंभ करते समय, वे पहले चर the p’ के मान का उपयोग करना चाहते थे। और यह पता चला कि दूसरा, अभी भी बिना किसी बदलाव के चर का उपयोग किया जाता है।

परियोजना के लेखकों के लिए। यहाँ एक नज़र डालें: 175.cpp को पुनर्स्थापित करें

खतरनाक स्ट्रिंग तुलना (भेद्यता)

ध्यान दें कि memcmp () फ़ंक्शन का परिणाम 'SSHORT' प्रकार के चर में रखा गया है। 'SSHORT' टाइप 'शॉर्ट' के पर्याय से ज्यादा कुछ नहीं है।

 SSHORT TextType::compare( ULONG len1, const UCHAR* str1, ULONG len2, const UCHAR* str2) { .... SSHORT cmp = memcmp(str1, str2, MIN(len1, len2)); if (cmp == 0) cmp = (len1 < len2 ? -1 : (len1 > len2 ? 1 : 0)); return cmp; } 

V642 'लघु' प्रकार चर के अंदर 'मेमकैंप' फ़ंक्शन परिणाम सहेजना अनुचित है। महत्वपूर्ण बिट्स प्रोग्राम के तर्क को तोड़ सकते हैं। texttype.cpp 338

क्या आपको आश्चर्य है कि यहाँ क्या गलत है?

आइए याद रखें कि मेमकैंप () फ़ंक्शन प्रकार 'int' का मान लौटाता है। लेकिन परिणाम 'लघु' प्रकार के चर में रखा गया है। सबसे महत्वपूर्ण बिट खो गए हैं। यह खतरनाक है!

फ़ंक्शन निम्न मान लौटाता है: शून्य से कम, शून्य या शून्य से अधिक। "शून्य से अधिक" से कुछ भी मतलब हो सकता है। यह 1, 2 या 19472341 हो सकता है। आप 'int' के आकार की तुलना में एक चर के लिए मेम्कैंप () फ़ंक्शन के परिणाम को नहीं बचा सकते हैं।

समस्या दूर की कौड़ी लग सकती है। लेकिन यह वास्तविक भेद्यता समस्या है। MySQL कोड में एक समान त्रुटि को भेद्यता के रूप में मान्यता दी गई थी: MySQL / MariaDB sql / password.c में सुरक्षा भेद्यता । वहां, परिणाम को 'char' प्रकार के एक चर में रखा गया था। सुरक्षा के दृष्टिकोण से 'छोटा' प्रकार बहुत बेहतर नहीं है।

इसी तरह की खतरनाक तुलनाएं यहां मिल सकती हैं:

• cvt2.cpp 256
• cvt2.cpp 522

शुद्धिपत्र

टाइपो हर जगह और हमेशा होते हैं। एक नियम के रूप में, उनमें से ज्यादातर परीक्षण की प्रक्रिया में जल्दी हैं। लेकिन वैसे भी, आप लगभग किसी भी परियोजना में टाइपोस पा सकते हैं।

 int Parser::parseAux() { .... if (yyps->errflag != yyps->errflag) goto yyerrlab; .... } 

V501 बाईं और 'के दाईं ओर समान उप-अभिव्यक्तियाँ हैं! =' ऑपरेटर: yyps-> इरफ़्लैग! = Yyps-> इरफ़्लैग parse.cpp 23523

मुझे लगता है कि टिप्पणियों की यहां जरूरत नहीं है। और यहाँ, शायद, कॉपी-पेस्ट का उपयोग किया गया था:

 bool CMP_node_match( const qli_nod* node1, const qli_nod* node2) { .... if (node1->nod_desc.dsc_dtype != node2->nod_desc.dsc_dtype || node2->nod_desc.dsc_scale != node2->nod_desc.dsc_scale || node2->nod_desc.dsc_length != node2->nod_desc.dsc_length) .... } 

V501 समान उप-अभिव्यक्तियाँ हैं 'नोड 2-> nod_desc.dsc_scale' बाईं ओर और '! =' ऑपरेटर के दाईं ओर। compile.cpp 156

V501 समान उप-अभिव्यक्तियाँ हैं 'नोड 2-> nod_desc.dsc_length' बाईं ओर और '! =' ऑपरेटर के दाईं ओर। compile.cpp 157

यह पता चला है कि CMP_node_match () फ़ंक्शन की तुलना में 'nod_desc.dsc_scale' और 'nod_desc.dsc_length' वर्ग के सदस्य गलत हैं।

परियोजना के लेखक यहां एक और टाइपो देख सकते हैं: compile.cpp 183

अजीब सा चक्र

 static processing_state add_row(TEXT* tabname) { .... unsigned i = n_cols; while (--i >= 0) { if (colnumber[i] == ~0u) { bldr->remove(fbStatus, i); if (ISQL_errmsg(fbStatus)) return (SKIP); } } msg.assignRefNoIncr(bldr->getMetadata(fbStatus)); .... } 

V547 अभिव्यक्ति '- i> = 0' हमेशा सत्य होती है। निरुपित प्रकार का मूल्य हमेशा> = 0. isql.cpp 3421 होता है

चर 'i' प्रकार का 'अहस्ताक्षरित' है। इसका अर्थ है कि चर 'i' हमेशा 0 से अधिक या बराबर होता है। परिणामस्वरूप, स्थिति (--i> = 0) का कोई मतलब नहीं है। यह हमेशा सच है।

यह चक्र, इसके विपरीत, आवश्यकता से पहले समाप्त हो जाएगा:

 SLONG LockManager::queryData(....) { .... for (const srq* lock_srq = (SRQ) SRQ_ABS_PTR(data_header.srq_backward); lock_srq != &data_header; lock_srq = (SRQ) SRQ_ABS_PTR(lock_srq->srq_backward)) { const lbl* const lock = ....; CHECK(lock->lbl_series == series); data = lock->lbl_data; break; } .... } 

यह संदिग्ध 'ब्रेक' क्या है?

इसी तरह की एक और स्थिति: pag.cpp 217

क्लासिक

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

 int CCH_down_grade_dbb(void* ast_object) { .... SyncLockGuard bcbSync( &bcb->bcb_syncObject, SYNC_EXCLUSIVE, "CCH_down_grade_dbb"); bcb->bcb_flags &= ~BCB_exclusive; if (bcb && bcb->bcb_count) .... } 

N5ptr के खिलाफ सत्यापित होने से पहले V595 'bcb' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 271, 274. cch.cpp 271

शुरुआत में, सूचक 'bcb' को "bcb-> bcb_flags & = ...." की अभिव्यक्ति में चित्रित किया गया है। निम्नलिखित जांच से पता चलता है कि 'बीसीबी' शून्य हो सकता है।

ऐसी जगहों की सूची (31 चेतावनियाँ): फायरबर्ड-वी 595. टेक्स्ट

ऑपरेटरों को शिफ्ट करें

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

 const ULONG END_BUCKET = (~0) << 1; 

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

ऋणात्मक संख्याओं को स्थानांतरित नहीं किया जा सकता है। और पढ़ें: " बिना कांटे को जाने, पानी में नहीं उतरें। भाग तीन ।"

यहां ऐसा करना बेहतर है:

 const ULONG END_BUCKET = (~0u) << 1; 

और दो और खराब बदलाव:

• exprnodes.cpp 6185
• array.cpp 845

अर्थहीन जाँच

 static processing_state add_row(TEXT* tabname) { .... unsigned varLength, scale; .... scale = msg->getScale(fbStatus, i); .... if (scale < 0) .... } 

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

चर 'स्केल' प्रकार का 'अहस्ताक्षरित' है। तुलना (पैमाने <0) का कोई मतलब नहीं है।

सदृश: isql.cpp 4437

आइए एक और समारोह देखें:

 static bool get_switches(....) .... if (**argv != 'n' || **argv != 'N') { fprintf(stderr, "-sqlda : " "Deprecated Feature: you must use XSQLDA\n "); print_switches(); return false; } .... } 

गलत कमांड लाइन तर्क। दशा (** argv! = 'N' || ** argv! = 'N') हमेशा संतुष्ट रहती है।

अनेक वस्तुओं का संग्रह

 void FB_CARG Why::UtlInterface::getPerfCounters( ...., ISC_INT64* counters) { unsigned n = 0; .... memset(counters, 0, n * sizeof(ISC_INT64)); .... } 

V575 'मेमसेट' फ़ंक्शन '0' तत्वों को प्रोसेस करता है। तीसरे तर्क का निरीक्षण करें। perf.cpp 487

ऐसा लगता है कि फ़ंक्शन के शरीर में चर 'एन' शून्य के अलावा एक मूल्य निर्दिष्ट करना भूल गया था।

तीसरे तर्क के रूप में कनवर्ट () फ़ंक्शन स्ट्रिंग की लंबाई लेता है:

 ULONG convert(const ULONG srcLen, const UCHAR* src, const ULONG dstLen, UCHAR* dst, ULONG* badInputPos = NULL, bool ignoreTrailingSpaces = false); 

हालाँकि, फ़ंक्शन गलत तरीके से उपयोग किया जाता है:

 string IntlUtil::escapeAttribute(....) { .... ULONG l; UCHAR* uc = (UCHAR*)(&l); const ULONG uSize = cs->getConvToUnicode().convert(size, p, sizeof(uc), uc); .... } 

V579 परिवर्तित फ़ंक्शन सूचक और उसके आकार को तर्क के रूप में प्राप्त करता है। यह संभवतः एक गलती है। तीसरे तर्क का निरीक्षण करें। intlutil.cpp 668

हम 64-बिट त्रुटि के साथ काम कर रहे हैं जो Win64 में खुद को प्रकट करेगा।

अभिव्यक्ति 'साइज़ोफ़ (uc)' पॉइंटर के आकार को लौटाता है, बफर के आकार को नहीं। यह डरावना नहीं है अगर पॉइंटर का आकार 'अहस्ताक्षरित लंबे' प्रकार के चर के आकार से मेल खाता है। यदि हम लिनक्स के लिए प्रोग्राम करते हैं तो पॉइंटर का आकार 'लॉन्ग' प्रकार के आकार के समान है। Win32 में कोई समस्या नहीं होगी।

त्रुटि तब होती है जब हम Win64 के लिए आवेदन संकलित करते हैं। कन्वर्ट () फ़ंक्शन सोचेंगे कि बफर का आकार 8 बाइट्स (पॉइंटर आकार) है। वास्तव में, बफर का आकार 4 बाइट्स है।

नोट। शायद कार्यक्रम में अन्य 64-बिट त्रुटियां हैं। लेकिन मैंने उचित निदान का अध्ययन नहीं किया। उनके बारे में लिखना उबाऊ है और कार्यक्रम को जाने बिना यह समझना मुश्किल है कि कोई गलती होगी या नहीं। सामान्य चेतावनी का अध्ययन करते समय वर्णित 64-बिट समस्या अप्रत्यक्ष रूप से पाई गई थी।

निष्कर्ष

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