कैलकुलेटर के नक्शेकदम पर चलें: कलकलेट

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

परिचय

Qalculate! एक बहुउद्देश्यीय क्रॉस-प्लेटफॉर्म डेस्कटॉप कैलकुलेटर है। यह उपयोग करने के लिए सरल है लेकिन आम तौर पर जटिल गणित पैकेजों के लिए आरक्षित शक्ति और बहुमुखी प्रतिभा प्रदान करता है, साथ ही रोजमर्रा की जरूरतों के लिए उपयोगी उपकरण (जैसे मुद्रा रूपांतरण और प्रतिशत गणना)। परियोजना में दो घटक शामिल हैं: libqalculate (पुस्तकालय और CLI) और qalculate-gtk (GTK + UI)। अध्ययन में केवल libqalculate कोड शामिल था।

विंडोज कैलकुलेटर के साथ प्रोजेक्ट की आसानी से तुलना करने के लिए, जिसे हमने हाल ही में जांचा है, मैं libqalculal के लिए क्लोक उपयोगिता के आउटपुट का हवाला दे रहा हूं:

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

वैसे, यहां Microsoft से कैलकुलेटर की जांच के बारे में एक लेख का लिंक दिया गया है: " विंडोज कैलकुलेटर में कीड़े गिनना "।

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

कॉपी-पेस्ट और टाइपो फिर से!

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। नंबर.सीसी 4018

bool Number::square() { .... if(mpfr_cmpabs(i_value->internalLowerFloat(), i_value->internalUpperFloat()) > 0) { mpfr_sqr(f_tmp, i_value->internalLowerFloat(), MPFR_RNDU); mpfr_sub(f_rl, f_rl, f_tmp, MPFR_RNDD); } else { mpfr_sqr(f_tmp, i_value->internalLowerFloat(), MPFR_RNDU); mpfr_sub(f_rl, f_rl, f_tmp, MPFR_RNDD); } .... } 

कोड बिल्कुल और अगर ब्लॉक में समान है । आसन्न कोड के टुकड़े इस एक के समान हैं, लेकिन उनमें अलग-अलग फ़ंक्शन का उपयोग किया जाता है: internalLowerFloat () और internalUpperFloat () । यह मान लेना सुरक्षित है कि एक डेवलपर ने कोड की प्रतिलिपि बनाई और यहां फ़ंक्शन का नाम सही करना भूल गया।

V501 समान उप-अभिव्यक्तियाँ हैं '! Mtr2.number ()। IsReal ()' बाईं ओर और दाईं ओर '' || ऑपरेटर। बिलिनफैक्शन .cc 6274

 int IntegrateFunction::calculate(....) { .... if(!mtr2.isNumber() || !mtr2.number().isReal() || !mtr.isNumber() || !mtr2.number().isReal()) b_unknown_precision = true; .... } 

इस मामले में, इस तथ्य के कारण डुप्लिकेट किए गए अभिव्यक्तियां इस तथ्य के कारण दिखाई देती हैं कि एक स्थान पर mtr2 को mtr के बजाय लिखा गया था । इस प्रकार, mtr.number ()। IsReal () फ़ंक्शन की कॉल स्थिति में अनुपस्थित है।

V501 समान उप-अभिव्यक्तियाँ हैं 'vargs [1] .representsNonPositive ()' बाईं ओर और 'दाईं ओर' || ऑपरेटर। बिलिनफंक्शंस .cc 5785



हमें इस कोड में मैन्युअल रूप से कभी भी दोष नहीं मिला होगा! लेकिन यहाँ हैं। इसके अलावा, मूल फ़ाइल में ये टुकड़े एक पंक्ति में लिखे गए हैं। एनालाइज़र ने एक डुप्लिकेटेड एक्सप्रेशन वर्जन [1] .representsNonPositive () का पता लगाया है, जो एक टाइपो या, परिणामस्वरूप, एक संभावित त्रुटि का संकेत दे सकता है।

यहाँ संदिग्ध स्थानों की पूरी सूची है, जिन्हें कोई भी मुश्किल से निकाल सकता है।

• V501 समान उप-अभिव्यक्तियाँ हैं 'vargs [1] .representsNonPositive ()' बाईं ओर और 'दाईं ओर' || ऑपरेटर। बिलिनफंक्शंस .cc 5788
• V501 बाईं ओर और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति 'परिशिष्ट' हैं। MathStructure.cc 1780
• V501 बाईं ओर और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति 'परिशिष्ट' हैं। मैथस्ट्रक्चर.सीसी 2043
• V501 समान उप-अभिव्यक्तियाँ हैं (* * v_subs [v_order [1]])। बाईं ओर और '&&' ऑपरेटर के दाईं ओर स्थित रिप्रेजेंट नेशनेटिव (ट्रू)। MathStructure.cc 5569

गलत हालत के साथ पाश

V534 यह संभावना है कि 'के लिए' ऑपरेटर के अंदर एक गलत चर की तुलना की जा रही है। 'I' की समीक्षा करने पर विचार करें। MathStructure.cc 28741

 bool MathStructure::isolate_x_sub(....) { .... for(size_t i = 0; i < mvar->size(); i++) { if((*mvar)[i].contains(x_var)) { mvar2 = &(*mvar)[i]; if(mvar->isMultiplication()) { for(size_t i2 = 0; i < mvar2->size(); i2++) { if((*mvar2)[i2].contains(x_var)) {mvar2 = &(*mvar2)[i2]; break;} } } break; } } .... } 

आंतरिक लूप में, i2 चर एक काउंटर का प्रतिनिधित्व करता है, लेकिन टाइपो के कारण एक त्रुटि हुई थी - बाहरी लूप से i चर का उपयोग लूप से बाहर निकलने की स्थिति में किया जाता है।

अतिरेक या एक त्रुटि?

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

 bool Number::add(const Number &o, MathOperation op) { .... if(i1 >= COMPARISON_RESULT_UNKNOWN && (i2 == COMPARISON_RESULT_UNKNOWN || i2 != COMPARISON_RESULT_LESS)) return false; .... } 

3 साल पहले जब मुझे इस तरह के कोड का पता चला, तो मैंने मेरे और अन्य डेवलपर्स के लिए एक चिट्ठी लिखी: " लॉजिकल एक्सप्रेशंस इन सी / सी ++। मिस्टेक्स मेड बाय प्रोफेशनल्स "। जब मैं इस तरह के कोड में आता हूं, तो मुझे यकीन है कि नोट कम प्रासंगिक नहीं है। आप लेख में देख सकते हैं, कोड के अनुरूप त्रुटि का एक पैटर्न ढूंढ सकते हैं, और सभी बारीकियों का पता लगा सकते हैं।

इस उदाहरण के मामले में, हम अनुभाग "अभिव्यक्ति ==" पर जाएंगे ! = "और पता करें कि अभिव्यक्ति i2 == COMPARISON_RESULT_UNKNOWN कुछ भी प्रभावित नहीं करता है।

Dereferencing अनियंत्रित संकेत

V595 nullptr के खिलाफ सत्यापित होने से पहले 'o_data' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 1108, 1112. डेटासेट.सीसी 1108

 string DataObjectArgument::subprintlong() const { string str = _("an object from"); str += " \""; str += o_data->title(); // <= str += "\""; DataPropertyIter it; DataProperty *o = NULL; if(o_data) { // <= o = o_data->getFirstProperty(&it); } .... } 

एक फ़ंक्शन में o_data पॉइंटर को चेक के बिना और बिना दोनों के साथ वितरित किया गया है। यह अनावश्यक कोड, या संभावित त्रुटि हो सकती है। मैं बाद की ओर झुक रहा हूं।

दो समान स्थान हैं:

• V595 nullptr के खिलाफ सत्यापित होने से पहले 'o_assumption' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 229, 230. चर। 229
• V595 nullptr के खिलाफ सत्यापित होने से पहले 'i_value' पॉइंटर का उपयोग किया गया था। चेक लाइन: 3412, 3427. नंबर। 3412

मुफ्त () या हटाना [?

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

 string Number::print(....) const { .... while(!exact && precision2 > 0) { if(try_infinite_series) { remcopy = new mpz_t[1]; // <= mpz_init_set(*remcopy, remainder); } mpz_mul_si(remainder, remainder, base); mpz_tdiv_qr(remainder, remainder2, remainder, d); exact = (mpz_sgn(remainder2) == 0); if(!started) { started = (mpz_sgn(remainder) != 0); } if(started) { mpz_mul_si(num, num, base); mpz_add(num, num, remainder); } if(try_infinite_series) { if(started && first_rem_check == 0) { remainders.push_back(remcopy); } else { if(started) first_rem_check--; mpz_clear(*remcopy); free(remcopy); // <= } } .... } .... } 

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

खोया हुआ बदलाव

 bool expand_partial_fractions(MathStructure &m, ....) { .... if(b_poly && !mquo.isZero()) { MathStructure m = mquo; if(!mrem.isZero()) { m += mrem; m.last() *= mtest[i]; m.childrenUpdated(); } expand_partial_fractions(m, eo, false); return true; } .... } 

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

अजीब बात है

V774 मेमोरी जारी होने के बाद 'cu' पॉइंटर का उपयोग किया गया था। कैलक्यूलेटर .cc 3595

 MathStructure Calculator::convertToBestUnit(....) { .... CompositeUnit *cu = new CompositeUnit("", "...."); cu->add(....); Unit *u = getBestUnit(cu, false, eo.local_currency_conversion); if(u == cu) { delete cu; // <= return mstruct_new; } delete cu; // <= if(eo.approximation == APPROXIMATION_EXACT && cu->hasApproximateRelationTo(u, true)) { // <= if(!u->isRegistered()) delete u; return mstruct_new; } .... } 

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

खोज फ़ंक्शन का उपयोग

V797 'खोज' फ़ंक्शन का उपयोग इस तरह किया जाता है जैसे कि यह एक बूल प्रकार लौटा हो। फ़ंक्शन का रिटर्न मान शायद std :: string :: npos के साथ तुलना की जानी चाहिए। Unit.cc 404

 MathStructure &AliasUnit::convertFromFirstBaseUnit(....) const { if(i_exp != 1) mexp /= i_exp; ParseOptions po; if(isApproximate() && suncertainty.empty() && precision() == -1) { if(sinverse.find(DOT) || svalue.find(DOT)) po.read_precision = READ_PRECISION_WHEN_DECIMALS; else po.read_precision = ALWAYS_READ_PRECISION; } .... } 

हालांकि कोड सफलतापूर्वक संकलित किया जा सकता है, यह संदेहास्पद लगता है, क्योंकि खोज फ़ंक्शन प्रकार std :: string :: size_bype की संख्या देता है। यदि यह बिंदु स्ट्रिंग के किसी भी भाग में पाया जाता है तो स्थिति सही होगी, सिवाय इसके कि बिंदु शुरुआत में है। यह एक अजीब जाँच है। मुझे यकीन नहीं है लेकिन, शायद, इस कोड को इस प्रकार फिर से लिखा जाना चाहिए:

 if( sinverse.find(DOT) != std::string::npos || svalue.find(DOT) != std::string::npos) { po.read_precision = READ_PRECISION_WHEN_DECIMALS; } 

संभावित स्मृति रिसाव

V701 realloc () संभावित रिसाव: जब realloc () मेमोरी आवंटित करने में विफल रहता है, तो मूल पॉइंटर 'बफर' खो जाता है। एक अस्थायी पॉइंटर को realloc () असाइन करने पर विचार करें। 70.cc का उपयोग करें

 char *utf8_strdown(const char *str, int l) { #ifdef HAVE_ICU .... outlength = length + 4; buffer = (char*) realloc(buffer, outlength * sizeof(char)); // <= .... #else return NULL; #endif } 

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

निष्कर्ष

द कलकुलेट! सर्वश्रेष्ठ मुफ्त कैलकुलेटर की सूची में परियोजना सबसे ऊपर है, जबकि इसमें कई गंभीर त्रुटियां हैं। दूसरी ओर, हमने अभी तक इसके प्रतियोगियों की जाँच नहीं की है। हम सभी लोकप्रिय कैलकुलेटर पर जाने की कोशिश करेंगे।

विंडोज की दुनिया से कैलकुलेटर की गुणवत्ता की तुलना करने के लिए, Microsoft की उपयोगिता अब तक अधिक विश्वसनीय और अच्छी तरह से काम करती है।

अपने खुद के "कैलकुलेटर" की जांच करें - पीवीएस-स्टूडियो डाउनलोड करें और इसे अपनी परियोजना के लिए आज़माएं। :-)