पीवीएस-स्टूडियो बनाम क्रोमियम

इस बार जीत अच्छी रही। या बल्कि, क्रोमियम परियोजना का स्रोत कोड। क्रोमियम उन सर्वश्रेष्ठ परियोजनाओं में से एक है जिसका हमने पीवीएस-स्टूडियो का उपयोग करके परीक्षण किया था।

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

प्रोग्रामर के दृष्टिकोण से, क्रोमियम 473 परियोजनाओं से युक्त एक समाधान है। C / C ++ में स्रोत कोड की कुल राशि लगभग 460 मेगाबाइट है। लाइनों की संख्या की गणना करना मुश्किल है।

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

क्रोमियम सबसे बड़ी और सबसे उच्च गुणवत्ता वाली परियोजना थी जो मुझे पीवीएस-स्टूडियो के परीक्षणों के दौरान मिली थी। क्रोमियम परियोजना के साथ काम करते समय, यह वास्तव में बहुत स्पष्ट नहीं था कि कौन किसकी जाँच कर रहा है। हमने C ++ फ़ाइलों के विश्लेषण से संबंधित PVS-Studio में कई त्रुटियां पाईं और ठीक कर दीं और परियोजना की विशिष्ट संरचना के लिए समर्थन किया।

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

int XX[] = { 1, 2, 3, 4 }; size_t N = sizeof(XX) / sizeof(XX[0]); 

यह आमतौर पर निम्नलिखित फॉर्म के एक मैक्रो में किया जाता है:

 #define count_of(arg) (sizeof(arg) / sizeof(arg[0])) 

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

 void Test(int C[3]) { int A[3]; int *B = Foo(); size_t x = count_of( A ); // Ok x = count_of( B ); // Error x = count_of( C ); // Error } 

Count_of (A) निर्माण कार्य सही ढंग से करता है और सरणी A में तत्वों की संख्या तीन के बराबर देता है।

लेकिन अगर आप गलती से count_of () को पॉइंटर पर लागू करते हैं, तो परिणाम एक अर्थहीन मूल्य होगा। परेशानी यह है कि मैक्रो प्रोग्रामर को किसी भी तरह से फॉर्म काउंट_ऑफ (बी) के एक अजीब निर्माण के बारे में चेतावनी नहीं देता है। सूचक का आकार सरणी तत्व के आकार से विभाजित किया गया है। यह स्थिति दूर की कौड़ी और कृत्रिम लगती है, लेकिन मैं इसे वास्तविक अनुप्रयोगों में मिला। मैं मिरांडा IM परियोजना से एक उदाहरण दूंगा:

 #define SIZEOF(X) (sizeof(X)/sizeof(X[0])) int Cache_GetLineText(..., LPTSTR text, int text_size, ...) { ... tmi.printDateTime(pdnce->hTimeZone, _T("t"), text, SIZEOF(text), 0); ... } 

इसलिए ऐसी त्रुटियां काफी हद तक होती हैं और उनके खिलाफ बचाव करने में सक्षम होना अच्छा होगा। यदि आप तर्क के रूप में पारित सरणी के आकार की गणना करने का प्रयास करते हैं, तो गलती करना और भी आसान है:

 void Test(int C[3]) { x = count_of( C ); // Error } 

C ++ भाषा मानक के अनुसार, चर 'C' एक साधारण सूचक है, न कि एक सरणी। नतीजतन, कार्यक्रमों में एक अक्सर ट्रांसफर किए गए सरणी के केवल भाग का ही प्रसंस्करण कर पाता है।
चूंकि हम ऐसी त्रुटियों के बारे में बात कर रहे हैं, इसलिए मैं आपको बताऊंगा कि प्रेषित सरणी के आकार का पता कैसे लगाया जाए। ऐसा करने के लिए, इसे लिंक द्वारा पास करें:

 void Test(int (&C)[3]) { x = count_of( C ); // Ok } 

अब अभिव्यक्ति count_of (C) का परिणाम 3 है।

वापस क्रोमियम के लिए। यह एक मैक्रो का उपयोग करता है जो ऊपर वर्णित त्रुटियों से बचा जाता है। यहाँ इसका कार्यान्वयन है:

 template <typename T, size_t N> char (&ArraySizeHelper(T (&array)[N]))[N]; #define arraysize(array) (sizeof(ArraySizeHelper(array))) 

इस जादू मंत्र का विचार इस प्रकार है। ArraySizeHelper टेम्पलेट फ़ंक्शन लंबाई N के एक मनमाने प्रकार के सरणी के इनपुट को स्वीकार करता है। फ़ंक्शन लंबाई 'char' तत्वों की एक सरणी देता है N। फ़ंक्शन का कोई कार्यान्वयन नहीं है, क्योंकि इसकी आवश्यकता नहीं है। आकार-प्रकार () ऑपरेटर के लिए, केवल ऐरेसाइज़ हेल्पर फ़ंक्शन की घोषणा करना पर्याप्त है। 'Arraysize' मैक्रो ArraySizeHelper फ़ंक्शन द्वारा दिए गए बाइट सरणी के आकार की गणना करता है। यह आकार सरणी में उन तत्वों की संख्या है जिनकी लंबाई हम गणना करना चाहते हैं।

यदि आपका सिर सूज गया है, तो आप इसके लिए मेरा शब्द ले सकते हैं कि यह काम करता है। और यह पहले से समझे गए मैक्रो 'count_of ()' से बहुत बेहतर है। चूंकि ArraySizeHelper फ़ंक्शन संदर्भ द्वारा एक सरणी लेता है, इसलिए इसे एक साधारण पॉइंटर पास करना संभव नहीं है। आइए एक परीक्षण कोड लिखें:

 template <typename T, size_t N> char (&ArraySizeHelper(T (&array)[N]))[N]; #define arraysize(array) (sizeof(ArraySizeHelper(array))) void Test(int C[3]) { int A[3]; int *B = Foo(); size_t x = arraysize( A ); // Ok x = arraysize( B ); //   x = arraysize( C ); //   } 

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

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

 if (!file_util::Delete(db_name, false) && !file_util::Delete(db_name, false)) { // Try to delete twice. If we can't, fail. LOG(ERROR) << "unable to delete old TopSites file"; return false; } 

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

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

 V512 A call of the 'memset' function will lead to underflow of the buffer '(exploded)'. platform time_win.cc 116 

 void NaCl::Time::Explode(bool is_local, Exploded* exploded) const { ... ZeroMemory(exploded, sizeof(exploded)); ... } 

टाइपो यह सब करते हैं। वे सिर्फ स्टार को भूल गए। यह होना चाहिए था: sizeof (* विस्फोट)।

 V502 Perhaps the '?:' operator works in a different way than it was expected. The '?:' operator has a lower priority than the '-' operator. views custom_frame_view.cc 400 

 static const int kClientEdgeThickness; int height() const; bool ShouldShowClientEdge() const; void CustomFrameView::PaintMaximizedFrameBorder(gfx::Canvas* canvas) { ... int edge_height = titlebar_bottom->height() - ShouldShowClientEdge() ? kClientEdgeThickness : 0; ... } 

कपटी संचालक "?:" घटाव की तुलना में कम प्राथमिकता है। अतिरिक्त कोष्ठक यहाँ आवश्यक हैं:

 int edge_height = titlebar_bottom->height() - (ShouldShowClientEdge() ? kClientEdgeThickness : 0); 

एक चेक जो समझ में नहीं आता है।

 V547 Expression 'count < 0' is always false. Unsigned type value is never < 0. ncdecode_tablegen ncdecode_tablegen.c 197 

 static void CharAdvance(char** buffer, size_t* buffer_size, size_t count) { if (count < 0) { NaClFatal("Unable to advance buffer by count!"); } else { ... } 

शर्त "गिनती <0" हमेशा झूठी होती है। संरक्षण काम नहीं करेगा और संभावित रूप से कुछ बफर पूर्ण हो सकते हैं। यह, वैसे, उदाहरण है कि कमजोरियों की खोज करने के लिए स्थिर विश्लेषणकर्ताओं का उपयोग कैसे किया जा सकता है। एक हमलावर जल्दी से खुद के लिए कोड के उन वर्गों को पहचान सकता है जिनमें उनके आगे, अधिक सावधानीपूर्वक विश्लेषण के लिए त्रुटियां हैं। यहाँ एक और कोड कोड है जो सुरक्षा की दृष्टि से दिलचस्प हो सकता है:

 V511 The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof (salt)' expression. common visitedlink_common.cc 84 

 void MD5Update(MD5Context* context, const void* buf, size_t len); VisitedLinkCommon::Fingerprint VisitedLinkCommon::ComputeURLFingerprint( ... const uint8 salt[LINK_SALT_LENGTH]) { ... MD5Update(&ctx, salt, sizeof(salt)); ... } 

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

सही कोड इस तरह दिखना चाहिए:

 MD5Update(&ctx, salt, sizeof(salt[0]) * LINK_SALT_LENGTH); 

या इस तरह:

 VisitedLinkCommon::Fingerprint VisitedLinkCommon::ComputeURLFingerprint( ... const uint8 (&salt)[LINK_SALT_LENGTH]) { ... MD5Update(&ctx, salt, sizeof(salt)); ... } 

एक अन्य टाइपो उदाहरण:

 V501 There are identical sub-expressions 'host != buzz::XmlConstants::str_empty ()' to the left and to the right of the '&&' operator. chromoting_jingle_glue iq_request.cc 248 

 void JingleInfoRequest::OnResponse(const buzz::XmlElement* stanza) { ... std::string host = server->Attr(buzz::QN_JINGLE_INFO_HOST); std::string port_str = server->Attr(buzz::QN_JINGLE_INFO_UDP); if (host != buzz::STR_EMPTY && host != buzz::STR_EMPTY) { ... } 

वास्तव में, आपको port_str चर की जाँच करने की आवश्यकता है:

 if (host != buzz::STR_EMPTY && port_str != buzz::STR_EMPTY) { 

क्लासिक्स से थोड़ा सा:

 V530 The return value of function 'empty' is required to be utilized. chrome_frame_npapi np_proxy_service.cc 293 

 bool NpProxyService::GetProxyValueJSONString(std::string* output) { DCHECK(output); output->empty(); ... } 

यह होना चाहिए: आउटपुट-> स्पष्ट ();

लेकिन वहाँ भी एक शून्य सूचक के साथ काम है:

 V522 Dereferencing of the null pointer 'plugin_instance' might take place. Check the logical condition. chrome_frame_npapi chrome_frame_npapi.cc 517 

 bool ChromeFrameNPAPI::Invoke(...) { ChromeFrameNPAPI* plugin_instance = ChromeFrameInstanceFromNPObject(header); if (!plugin_instance && (plugin_instance->automation_client_.get())) return false; ... } 

एक और परीक्षा उदाहरण जो कभी काम नहीं करेगा:

 V547 Expression 'current_idle_time < 0' is always false. Unsigned type value is never < 0. browser idle_win.cc 23 

 IdleState CalculateIdleState(unsigned int idle_threshold) { ... DWORD current_idle_time = 0; ... // Will go -ve if we have been idle for a long time (2gb seconds). if (current_idle_time < 0) current_idle_time = INT_MAX; ... } 

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

 V554 Incorrect use of auto_ptr. The memory allocated with 'new []' will be cleaned using 'delete'. interactive_ui_tests accessibility_win_browsertest.cc 306 

 void AccessibleChecker::CheckAccessibleChildren(IAccessible* parent) { ... auto_ptr<VARIANT> child_array(new VARIANT[child_count]); ... } 

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

 V547 Expression '* string != 0 || * string != '_'' is always true. Probably the '&&' operator should be used here. icui18n ucol_sit.cpp 242 

 U_CDECL_BEGIN static const char* U_CALLCONV _processVariableTop(...) { ... if(i == locElementCapacity && (*string != 0 || *string != '_')) { *status = U_BUFFER_OVERFLOW_ERROR; } ... } 

अभिव्यक्ति "(* स्ट्रिंग! = 0 || * स्ट्रिंग! = '_')" हमेशा सच है। जाहिर तौर पर यह होना चाहिए: (* string == 0 || * string == '_')।

निष्कर्ष

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

पुनश्च

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

पी पी एस

नहीं, हम लालची नहीं हैं। हम फ्लाईलिंकडीसी ++ जैसी ओपन सोर्स परियोजनाओं की मदद के लिए तैयार हैं। लेकिन ये दो अलग चीजें हैं।