🧘🏾 ⚗️ 🐺 प्रोग्राम सोर्स कोड के स्टेटिक विश्लेषण में मशीन लर्निंग 🤮 💇🏾 🛌🏽

कार्यक्रम स्रोत कोड के स्टेटिक विश्लेषण में मशीन लर्निंग

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

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

नया दृष्टिकोण

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

दिलचस्प बात यह है कि उनमें से लगभग सभी को गेम चेंजर उत्पादों के रूप में तैनात किया गया है जो कृत्रिम बुद्धिमत्ता के कारण विकास प्रक्रिया में एक सफलता दिलाएंगे।

आइए कुछ प्रसिद्ध उदाहरण देखें:

DeepCode
इंफ़र, सैपिएन्ज़, सैफ़िक्स
Embold
स्रोत {d}
चतुर-कमेटी, प्रतिबद्ध सहायक
CodeGuru

DeepCode

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

वास्तव में, यह विश्लेषक आपके प्रोजेक्ट बेस के साथ आपके समाधान की तुलना करता है और आपको अन्य डेवलपर्स के अनुभव से अपेक्षित सर्वश्रेष्ठ समाधान प्रदान करता है।

मई 2018 में, डेवलपर्स ने कहा कि C ++ का समर्थन अपने रास्ते पर है, लेकिन अभी तक, यह भाषा समर्थित नहीं है। हालांकि, जैसा कि साइट पर कहा गया है, नई भाषा समर्थन को इस तथ्य के कारण कुछ हफ्तों में जोड़ा जा सकता है कि भाषा केवल एक चरण पर निर्भर करती है, जो कि पार्सिंग है।

साइट पर विश्लेषक के बुनियादी तरीकों के बारे में पोस्ट की एक श्रृंखला भी उपलब्ध है।

तर्क करना

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

Infer जावा, C, C ++, और Objective-C, फेसबुक द्वारा विकसित परियोजनाओं के लिए एक स्थिर विश्लेषक है। साइट के अनुसार, इसका उपयोग अमेज़ॅन वेब सेवाओं, ओकुलस, उबेर और अन्य लोकप्रिय परियोजनाओं में भी किया जाता है।

वर्तमान में, Infer null pointer dereference और मेमोरी लीक से संबंधित त्रुटियों को खोजने में सक्षम है। इंफर होरे के तर्क, पृथक्करण तर्क और द्वि-अपहरण, साथ ही साथ सार व्याख्या सिद्धांत पर आधारित है। इन तरीकों का उपयोग विश्लेषक को कार्यक्रम को विखंडू में तोड़ने और उन्हें स्वतंत्र रूप से विश्लेषण करने की अनुमति देता है।

आप अपनी परियोजनाओं पर इनफेर का उपयोग करने का प्रयास कर सकते हैं, लेकिन डेवलपर्स ने चेतावनी दी है कि फेसबुक परियोजनाओं के साथ यह लगभग 80% उपयोगी चेतावनी उत्पन्न करता है, कम सकारात्मक संख्या में झूठी सकारात्मक अन्य परियोजनाओं की गारंटी नहीं है। यहां कुछ त्रुटियां हैं जो इनफेर अब तक का पता नहीं लगा सकते हैं, लेकिन डेवलपर्स इन चेतावनियों को लागू करने पर काम कर रहे हैं:

सरणी सूचकांक सीमा से बाहर;
टाइप कास्टिंग अपवाद;
असत्यापित डेटा लीक;
दौड़ की स्थिति।

SapFix

SapFix एक स्वचालित संपादन उपकरण है। यह Sapienz, एक परीक्षण स्वचालन उपकरण और Infer स्थिर विश्लेषक से जानकारी प्राप्त करता है। हाल के परिवर्तनों और संदेशों के आधार पर, इंफर ने बग को ठीक करने के लिए कई रणनीतियों में से एक का चयन किया।

कुछ मामलों में, SapFix सभी परिवर्तनों या उनमें से कुछ हिस्सों को वापस करता है। अन्य मामलों में, यह फिक्सिंग पैटर्न के अपने सेट से एक पैच उत्पन्न करके समस्या को हल करने की कोशिश करता है। यह सेट प्रोग्रामर द्वारा एकत्र किए गए फिक्स के पैटर्न से खुद से बनाए गए फिक्स के सेट से बनता है। यदि ऐसा कोई पैटर्न किसी त्रुटि को ठीक नहीं करता है, तो SapFix एक सार सिंटैक्स ट्री में छोटे संशोधन करके स्थिति को समायोजित करने की कोशिश करता है जब तक कि संभावित समाधान नहीं मिलता है।

लेकिन एक संभावित समाधान पर्याप्त नहीं है, इसलिए SapFix एक-दो बिंदुओं के आधार पर कई समाधान एकत्र करता है: चाहे संकलन त्रुटियां हों, चाहे वह क्रैश हो, चाहे वह नए क्रैश का परिचय दे। एक बार जब संपादन पूरी तरह से जांच लिया जाता है, तो पैच को एक प्रोग्रामर द्वारा समीक्षा की जाती है, जो तय करेगा कि कौन से संपादन समस्या का हल करता है।

Embold

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

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

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

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

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

स्रोत {d}

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

मशीन लर्निंग के माध्यम से कोड विश्लेषण के लिए उनका दृष्टिकोण प्राकृतिक परिकल्पना पर आधारित है, जैसा कि " सॉफ़्टवेयर की प्राकृतिकता" लेख में उल्लिखित है।

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

इस परिकल्पना के आधार पर, कोड का आधार जितना बड़ा होता है, सांख्यिकीय गुण उतने ही अधिक होते हैं, और सीखने के माध्यम से प्राप्त मैट्रिक्स अधिक सटीक होते हैं।

स्रोत {d} में कोड का विश्लेषण करने के लिए, Babelfish सेवा का उपयोग किया जाता है, जो किसी भी उपलब्ध भाषा में कोड फ़ाइल को पार्स कर सकता है, एक सार सिंटैक्स ट्री प्राप्त कर सकता है और इसे एक सार्वभौमिक वाक्यविन्यास ट्री में परिवर्तित कर सकता है।

हालाँकि, स्रोत {d} कोड में त्रुटियों की खोज नहीं करता है। संपूर्ण परियोजना पर एमएल का उपयोग करते हुए पेड़ के आधार पर, स्रोत {d} परियोजना में और एक प्रतिबद्ध में कोड स्वरूपण, शैली का पता लगाता है। यदि नया कोड प्रोजेक्ट कोड शैली के अनुरूप नहीं है, तो यह कुछ संपादन करता है।

लर्निंग कई बुनियादी तत्वों पर केंद्रित है: रिक्त स्थान, सारणीकरण, लाइन ब्रेक आदि।

उनके प्रकाशन में इसके बारे में और पढ़ें: " स्टाइल-एनेलाइजर: व्याख्यात्मक अप्रतिष्ठित एल्गोरिदम के साथ कोड शैली की विसंगतियों को ठीक करना "।

सभी सभी, स्रोत {d} स्रोत कोड और परियोजना विकास प्रक्रिया पर विविध आँकड़े एकत्र करने के लिए एक विस्तृत मंच है: कोड समीक्षा के लिए डेवलपर्स की दक्षता गणना से लेकर समय की लागत तक।

चतुर वचन

क्लेवर-कमिट Ubisoft के सहयोग से मोज़िला द्वारा बनाया गया एक विश्लेषक है। यह Ubisoft और इसके चाइल्ड प्रोडक्ट कमिट असिस्ट द्वारा एक CLEVER (कंबाइनिंग लेवल ऑफ बग प्रिवेंशन एंड रिजॉल्यूशन टेक्निक्स) स्टडी पर आधारित है, जिसमें ऐसे संदिग्ध कमिट्स का पता लगाया जाता है जिनमें त्रुटि होने की संभावना होती है। चूंकि CLEVER कोड तुलना पर आधारित है, इसलिए यह खतरनाक कोड पर दोनों को इंगित कर सकता है और संभावित संपादन के लिए सुझाव दे सकता है। विवरण के अनुसार, 60-70% मामलों में क्लेवर-कमिट को समस्या वाले स्थान मिलते हैं और समान संभावना के साथ सही संपादन प्रदान करते हैं। सामान्य तौर पर, इस परियोजना के बारे में बहुत कम जानकारी होती है और त्रुटियों के बारे में यह पता लगाने में सक्षम होता है।

CodeGuru

हाल ही में कोडगुरु, जो कि अमेज़ॅन का एक उत्पाद है, मशीन लर्निंग का उपयोग करके विश्लेषक के अनुरूप हो गया है। यह एक मशीन सीखने की सेवा है जो आपको कोड में त्रुटियों को खोजने की अनुमति देती है, साथ ही इसमें महंगे क्षेत्रों की पहचान भी करती है। विश्लेषण अब तक केवल जावा कोड के लिए उपलब्ध है, लेकिन लेखक भविष्य में अन्य भाषाओं का समर्थन करने का वादा करते हैं। हालाँकि इसकी घोषणा हाल ही में की गई थी, लेकिन AWS (Amazon Web Services) के सीईओ एंडी जेसी का कहना है कि इसका उपयोग अमेज़न में लंबे समय से किया जा रहा है।

वेबसाइट का कहना है कि कोडगुरु अमेज़ॅन कोड आधार पर सीख रहा था, साथ ही साथ 10,000 से अधिक ओपन सोर्स प्रोजेक्ट्स पर भी।

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

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

यह भी कहा जाता है कि उपयोगकर्ता के कोड के लिए सिफारिशें उन पर प्रतिक्रिया प्राप्त करने के बाद सुधार करती हैं।

उन त्रुटियों की सूची, जिनका समीक्षक उत्तर देता है, वे काफी धुंधले हैं, क्योंकि कोई विशेष त्रुटि प्रलेखन प्रकाशित नहीं किया गया है:

सर्वश्रेष्ठ अभ्यास AWS
संगामिति
संसाधन लीक
गोपनीय जानकारी की कमी
कोडिंग के सामान्य "सर्वोत्तम अभ्यास"

हमारा संशयवाद

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

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

हम प्रत्येक दिशा के बारे में अलग से बात करेंगे, क्योंकि उनकी अलग-अलग कमियां हैं। उसके बाद, मुझे लगता है, पाठकों को मिलेगा कि हम मशीन सीखने की संभावनाओं से इनकार क्यों नहीं करते, लेकिन फिर भी उत्साह साझा नहीं करते हैं।

नोट। हम एक सार्वभौमिक स्थिर सामान्य उद्देश्य विश्लेषक विकसित करने के दृष्टिकोण से देखते हैं। हम विश्लेषक के विकास पर केंद्रित हैं, जिसे कोई भी टीम उपयोग कर पाएगी, न कि किसी विशिष्ट कोड आधार पर केंद्रित।

एक स्थैतिक विश्लेषक का मैनुअल शिक्षण

मान लें कि हम कोड में निम्नलिखित प्रकार की खामियों की तलाश शुरू करने के लिए ML का उपयोग करना चाहते हैं:

if (A == A)

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

तो क्या एमएल एल्गोरिदम का उपयोग करके कोड में ऐसे दोषों की पहचान करना संभव है? हाँ, यह है। बात यह है - हमें इसकी आवश्यकता क्यों है?

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

आखिरकार, हम न केवल (ए == ए) मामलों का पता लगाना चाहते हैं, बल्कि:

यदि (X && A == A)
अगर (A + 1 == A + 1)
अगर (A [i] == A [i])
अगर (ए) == (ए))
और इसी तरह।

आइए, पीवीएस-स्टूडियो में ऐसे सरल निदान के संभावित कार्यान्वयन को देखें:

 void RulePrototype_V501(VivaWalker &walker, const Ptree *left, const Ptree *right, const Ptree *operation) { if (SafeEq(operation, "==") && SafeEqual(left, right)) { walker.AddError("Oh boy! Holy cow!", left, 501, Level_1, "CWE-571"); } }

और वह यह है! आप एमएल के लिए उदाहरण के किसी भी आधार की जरूरत नहीं है!

भविष्य में, निदानकर्ता को कई अपवादों को ध्यान में रखना सीखना होगा और ([[0] == ए [१-१]] के लिए चेतावनी जारी करनी होगी। जैसा कि हम जानते हैं, यह आसानी से प्रोग्राम किया जा सकता है। इसके विपरीत, इस मामले में, उदाहरणों के आधार के साथ चीजें खराब होने वाली हैं।

ध्यान दें कि दोनों ही मामलों में हमें परीक्षण, प्रलेखन आदि की एक प्रणाली की आवश्यकता होगी। नए डायग्नोस्टिक बनाने पर श्रम योगदान के लिए, क्लासिक दृष्टिकोण, जहां नियम को कोड में क्रमादेशित किया जाता है, लीड लेता है।

ठीक है, यह एक और नियम के लिए समय है। उदाहरण के लिए, कुछ कार्यों के परिणाम का उपयोग किया जाना चाहिए। उन्हें कॉल करने और उनके परिणाम का उपयोग नहीं करने का कोई मतलब नहीं है। इस तरह के कुछ कार्य इस प्रकार हैं:

malloc
memcmp
स्ट्रिंग :: खाली

यह वही है जो पीवीएस-स्टूडियो वी 530 डायग्नोस्टिक करता है।

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

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

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

 uint32_t* BnNew() { uint32_t* result = new uint32_t[kBigIntSize]; memset(result, 0, kBigIntSize * sizeof(uint32_t)); return result; } std::string AndroidRSAPublicKey(crypto::RSAPrivateKey* key) { .... uint32_t* n = BnNew(); .... RSAPublicKey pkey; pkey.len = kRSANumWords; pkey.exponent = 65537; // Fixed public exponent pkey.n0inv = 0 - ModInverse(n0, 0x100000000LL); if (pkey.n0inv == 0) return kDummyRSAPublicKey; // <= .... }

उदाहरण " क्रोमियम: मेमोरी लीक्स " लेख से लिया गया है। यदि स्थिति (pkey.n0inv == 0) सत्य है, तो फ़ंक्शन बफर से मुक्त किए बिना बाहर निकल जाता है, जो पॉइंटर को n चर में संग्रहीत किया जाता है।

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

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

हम एमएल में विशेषज्ञ नहीं हैं, लेकिन हमें लगता है कि बड़ी समस्याएँ यहाँ के कोने के आसपास हैं। स्मृति लीक के साथ कोड लिखने के तरीके की एक अविश्वसनीय संख्या है। यहां तक कि अगर मशीन अच्छी तरह से सीखती है कि चर के मूल्यों को कैसे ट्रैक किया जाए, तो यह समझना होगा कि कार्यों के लिए कॉल भी हैं।

हमें संदेह है कि यह सीखने के लिए कई उदाहरणों की आवश्यकता होगी कि कार्य अस्वीकार्य हो जाता है। हम यह नहीं कह रहे हैं कि यह अवास्तविक है। हमें संदेह है कि विश्लेषक बनाने की लागत का भुगतान करना होगा।

सादृश्य। मेरे दिमाग में जो आता है वह एक कैलकुलेटर के साथ सादृश्य है, जहां निदान के बजाय, किसी को अंकगणितीय क्रियाओं को करना पड़ता है। हमें यकीन है कि आप एक एमएल आधारित कैलकुलेटर को 1 + 1 = 2, 1 + 2 = 3, 2 + 1 = 3, 100 + 200 = 300 और इसी तरह के कार्यों के परिणाम खिलाकर संख्याओं को अच्छी तरह से जोड़ सकते हैं। । जैसा कि आप समझते हैं, इस तरह के कैलकुलेटर को विकसित करने की व्यवहार्यता एक बड़ा सवाल है (जब तक कि इसे अनुदान आवंटित नहीं किया जाता है :)। कोड में सरल ऑपरेशन "+" का उपयोग करके बहुत सरल, तेज, अधिक सटीक और विश्वसनीय कैलकुलेटर लिखा जा सकता है।

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

ओपन सोर्स कोड की बड़ी मात्रा पर सीखना

ठीक है, हमने मैन्युअल सिंथेटिक उदाहरणों के साथ हल किया है, लेकिन इसमें GitHub भी है। आप इतिहास को ट्रैक कर सकते हैं और कोड बदलने / फिक्सिंग पैटर्न को घटा सकते हैं। फिर आप न केवल संदिग्ध कोड के टुकड़े पर इंगित कर सकते हैं, बल्कि कोड को ठीक करने का एक तरीका भी सुझा सकते हैं।

यदि आप इस विस्तार स्तर पर रुकते हैं, तो सब कुछ अच्छा लगता है। शैतान, हमेशा की तरह, विवरण में है। तो चलिए इन विवरणों के बारे में सही बात करते हैं।

पहली बारीकियाँ। डेटा स्रोत।

GitHub संपादन काफी यादृच्छिक और विविध हैं। लोग अक्सर परमाणु कमिट बनाने के लिए आलसी होते हैं और एक ही समय में कोड में कई संपादन करते हैं। आप जानते हैं कि यह कैसे होता है: आप बग को ठीक कर देंगे, और उसी समय इसे थोड़ा रिफैक्ट कर देगा ("और यहां मैं इस तरह के मामले से निपटने के लिए जोड़ूंगा ...")। यहां तक कि एक व्यक्ति तब समझ से बाहर हो सकता है, चाहे ये निश्चित एक-दूसरे से संबंधित हों या नहीं।

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

क्या ऐसा मार्कअप संभव है? हां! लेकिन ध्यान दें कि स्पूफिंग कितनी जल्दी होती है। "एल्गोरिथ्म गीथहब के आधार पर खुद को सीखता है" के बजाय हम पहले से ही सैकड़ों लोगों को लंबे समय तक पहेली बनाने के बारे में चर्चा कर रहे हैं। उपकरण बनाने का काम और लागत नाटकीय रूप से बढ़ रही है।

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

इसलिए, हमें अभी तक सीखने को नहीं मिला है, और पहले से ही बारीकियां हैं :)।

दूसरी बारीकियाँ। विकास में पिछड़ गया।

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

C # 8.0 के बाद से Nullable Reference type हुए हैं, जो Null Reference Exception (NRE) के खिलाफ लड़ने में मदद करते हैं। JDK 12 में, एक नया स्विच ऑपरेटर ( JEP 325 ) दिखाई दिया। सी ++ 17 में, संकलन-समय सशर्त निर्माण ( यदि हो तो विवश ) करने की संभावना है। और इसी तरह।

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

इस बिंदु पर, एमएल विधि एक समस्या का सामना करती है: त्रुटि पैटर्न पहले से ही स्पष्ट है, हम इसका पता लगाना चाहते हैं, लेकिन सीखने के लिए कोई कोड आधार नहीं है।

आइए एक विशेष उदाहरण का उपयोग करके इस समस्या को देखें। लूप के लिए रेंज-आधारित C ++ 11 में दिखाई दिया। आप निम्न कोड लिख सकते हैं, कंटेनर में सभी तत्वों को पीछे छोड़ते हुए:

 std::vector<int> numbers; .... for (int num : numbers) foo(num);

नया लूप अपने साथ नया एरर पैटर्न लाया है। यदि हम कंटेनर को लूप के अंदर बदलते हैं, तो इससे "छाया" पुनरावृत्तियों को अमान्य कर दिया जाएगा।

आइए निम्नलिखित गलत कोड पर एक नज़र डालें:

 for (int num : numbers) { numbers.push_back(num * 2); }

संकलक इसे कुछ इस तरह से बदल देगा:

 for (auto __begin = begin(numbers), __end = end(numbers); __begin != __end; ++__begin) { int num = *__begin; numbers.push_back(num * 2); }

पुश_बैक के दौरान, __begin और __end पुनरावृत्तियों को अमान्य किया जा सकता है, यदि मेमोरी वेक्टर के अंदर स्थानांतरित हो जाती है। परिणाम कार्यक्रम का अपरिभाषित व्यवहार होगा।

इसलिए, त्रुटि पैटर्न लंबे समय से साहित्य में ज्ञात और वर्णित है। PVS-Studio विश्लेषक V789 डायग्नोस्टिक के साथ इसका निदान करता है और पहले ही ओपन सोर्स प्रोजेक्ट्स में वास्तविक त्रुटियां पा चुका है।

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

कितने साल लगेंगे? पांच? दस?

दस बहुत अधिक है, या यह एक निराशावादी भविष्यवाणी है? दूर है। लेख लिखे जाने तक, C ++ 11 में लूप के लिए रेंज-आधारित होने से आठ साल हो चुके थे। लेकिन अभी तक हमारे डेटाबेस में इस तरह की त्रुटि के केवल तीन मामले हैं। तीन त्रुटियां ज्यादा नहीं हैं और कुछ नहीं। इस संख्या से किसी को निष्कर्ष नहीं निकालना चाहिए। मुख्य बात यह पुष्टि करना है कि ऐसा त्रुटि पैटर्न वास्तविक है और इसका पता लगाने के लिए समझ में आता है।

अब इस संख्या की तुलना करें, उदाहरण के लिए, इस त्रुटि पैटर्न के साथ: सूचक चेक से पहले dereferenced हो जाता है । कुल मिलाकर, हम पहले ही ओपन सोर्स प्रोजेक्ट्स की जाँच करते समय 1,716 ऐसे मामलों की पहचान कर चुके हैं।

शायद हमें छोरों के लिए रेंज-आधारित त्रुटियों की तलाश नहीं करनी चाहिए? नहीं। यह सिर्फ यह है कि प्रोग्रामर निष्क्रिय हैं, और यह ऑपरेटर बहुत धीरे-धीरे लोकप्रिय हो रहा है। धीरे-धीरे, क्रमशः और त्रुटियों के साथ दोनों अधिक कोड होंगे।

C ++ 11 के प्रकट होने के 10-15 साल बाद ही ऐसा होने की संभावना है। इससे एक दार्शनिक सवाल उठता है। मान लीजिए कि हम पहले से ही त्रुटि पैटर्न को जानते हैं, तो हम कई वर्षों तक इंतजार करेंगे जब तक कि हमारे पास ओपन सोर्स प्रोजेक्ट्स में कई त्रुटियां न हों। क्या ऐसा होगा?

यदि "हाँ", सभी एमएल आधारित विश्लेषणकर्ताओं के लिए "मानसिक विकास में देरी" का निदान करना सुरक्षित है।

यदि "नहीं", तो हमें क्या करना चाहिए? कोई उदाहरण नहीं हैं। उन्हें मैन्युअल रूप से लिखें? लेकिन इस तरह, हम पिछले अध्याय में वापस आते हैं, जहां हमने विकल्प का विस्तृत विवरण दिया है जब लोग सीखने के लिए उदाहरणों का एक पूरा पैक लिखेंगे।

यह किया जा सकता है, लेकिन शीघ्रता का सवाल फिर से उठता है। पीवीएस-स्टूडियो विश्लेषक में सभी अपवादों के साथ V789 नैदानिक का कार्यान्वयन कोड की केवल 118 लाइनें लेता है, जिनमें से 13 लाइनें टिप्पणी हैं। यही है, यह एक बहुत ही सरल निदान है, जिसे आसानी से क्लासिक तरीके से प्रोग्राम किया जा सकता है।

स्थिति किसी भी अन्य नवाचारों के समान होगी जो किसी भी अन्य भाषाओं में दिखाई देती हैं। जैसा कि वे कहते हैं, सोचने के लिए कुछ है।

तीसरी बारीकियाँ। प्रलेखन।

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

एमएल आधारित स्थैतिक विश्लेषणकर्ताओं के मामले में, दस्तावेज़ीकरण मुद्दा किसी भी तरह से हल हो गया है। यह माना जाता है कि विश्लेषक बस एक ऐसी जगह की ओर संकेत करेगा जो उसे संदेहास्पद लगता है और उसे ठीक करने का सुझाव भी दे सकता है। संपादन करने या न करने का निर्णय व्यक्ति पर निर्भर है। बस यहीं से मुसीबत शुरू होती है ... बिना पढ़े कोई निर्णय लेना आसान नहीं है, जिससे कोड में किसी विशेष स्थान पर विश्लेषक को संदेह होने लगता है।

बेशक, कुछ मामलों में, सब कुछ स्पष्ट होगा। मान लीजिए कि विश्लेषक इस कोड को इंगित करता है:

 char *p = (char *)malloc(strlen(src + 1)); strcpy(p, src);

और सुझाव दें कि हम इसे प्रतिस्थापित करते हैं:

 char *p = (char *)malloc(strlen(src) + 1); strcpy(p, src);

यह तुरंत स्पष्ट है कि प्रोग्रामर ने एक टाइपो बनाया और गलत जगह पर 1 जोड़ा। नतीजतन, आवश्यक से कम मेमोरी आवंटित की जाएगी।

यहाँ यह सब बिना दस्तावेज के भी स्पष्ट है। हालांकि, यह हमेशा मामला नहीं होगा।

कल्पना कीजिए कि विश्लेषक "चुपचाप" इस कोड को इंगित करता है:

 char check(const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }

और पता चलता है कि हम int के लिए वापसी मूल्य के चार प्रकार बदलते हैं:

 int check(const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }

चेतावनी के लिए कोई दस्तावेज नहीं है। जाहिर है, चेतावनी के संदेश में कोई पाठ नहीं होगा, अगर हम पूरी तरह से स्वतंत्र विश्लेषक के बारे में बात कर रहे हैं।

हम क्या करेंगे? क्या अंतर है? क्या ऐसा प्रतिस्थापन करने के लायक है?

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

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

शायद, उदाहरण असंबद्ध लग रहा था। आखिरकार, विश्लेषक ने एक कोड सुझाया जो बेहतर होने की संभावना है। ठीक है। आइए, इस बार एक बदलाव के लिए, जावा में, छद्मकोड के एक और उदाहरण को देखें।

 ObjectOutputStream out = new ObjectOutputStream(....); SerializedObject obj = new SerializedObject(); obj.state = 100; out.writeObject(obj); obj.state = 200; out.writeObject(obj); out.close();

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

 ObjectOutputStream out = new ObjectOutputStream(....); SerializedObject obj = new SerializedObject(); obj.state = 100; out.writeObject(obj); obj = new SerializedObject(); // The line is added obj.state = 200; out.writeObject(obj); out.close();

वस्तु को बदलने और उसे फिर से लिखने के बजाय, एक नई वस्तु बनाई जाती है और इसे क्रमबद्ध किया जाएगा।

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

आप कहेंगे यह स्पष्ट नहीं है। वास्तव में, यह समझ से बाहर है। और ऐसा हर समय रहेगा। इस तरह के "मूक" विश्लेषक के साथ काम करना यह समझने की कोशिश में एक अंतहीन अध्ययन होगा कि विश्लेषक कुछ भी क्यों पसंद नहीं करता है।

यदि प्रलेखन है, तो सब कुछ पारदर्शी हो जाता है। वर्ग java.io.ObjectOuputStream जो क्रमांकन के लिए उपयोग किया जाता है, लिखित वस्तुओं को कैश करता है। इसका मतलब है कि एक ही वस्तु को दो बार क्रमबद्ध नहीं किया जाएगा। कक्षा एक बार वस्तु को क्रमबद्ध करती है, और दूसरी बार धारा में उसी पहली वस्तु के संदर्भ में लिखती है। और पढ़ें: V6076 - आवर्तक क्रमांकन पहले क्रमांकन से कैश्ड ऑब्जेक्ट स्थिति का उपयोग करेगा।

हमें उम्मीद है कि हम प्रलेखन के महत्व को समझाने में कामयाब रहे। यहाँ सवाल आता है। एमएल आधारित विश्लेषक के लिए दस्तावेज कैसे दिखाई देंगे?

जब एक क्लासिक कोड विश्लेषक विकसित किया जाता है, तो सब कुछ सरल और स्पष्ट होता है। त्रुटियों का एक पैटर्न है। हम इसे प्रलेखन में वर्णित करते हैं और नैदानिक को लागू करते हैं।

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

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

नोट। आप तर्क दे सकते हैं कि प्रलेखन वैकल्पिक है। विश्लेषक GitHub और उस व्यक्ति पर किए गए सुधारों के कई उदाहरणों का उल्लेख कर सकते हैं, उन्हें कमिट और टिप्पणियों के माध्यम से देख कर समझ पाएंगे कि क्या है। हां, ऐसा है। लेकिन विचार आकर्षक नहीं लगता। यहां विश्लेषक बुरा दोस्त है, जो उसकी मदद करने के बजाय एक प्रोग्रामर की पहेली करेगा।

चौथा संज्ञा। अति विशिष्ट भाषाएँ।

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

आइए इसे एक ठोस उदाहरण का उपयोग करके देखें। सबसे पहले, GitHub पर जाएं और लोकप्रिय जावा भाषा के लिए रिपॉजिटरी खोजें।

परिणाम: भाषा: "जावा": 3,128,884 उपलब्ध रिपॉजिटरी परिणाम

अब रूसी कंपनी 1 सी द्वारा उत्पादित लेखांकन अनुप्रयोगों में प्रयुक्त विशेष भाषा "1 सी एंटरप्राइज" को लें।

परिणाम: भाषा: "1 सी एंटरप्राइज": 551 उपलब्ध रिपॉजिटरी परिणाम

हो सकता है कि इस भाषा के लिए विश्लेषणकर्ताओं की आवश्यकता न हो? नहीं, वे हैं। ऐसे कार्यक्रमों का विश्लेषण करने की व्यावहारिक आवश्यकता है और पहले से ही उपयुक्त विश्लेषक हैं। उदाहरण के लिए, कंपनी " सिल्वर बुलेट " द्वारा निर्मित सोनारक्यूब 1 सी (बीएसएल) प्लगिन है।

मुझे लगता है कि कोई विशिष्ट स्पष्टीकरण की आवश्यकता नहीं है क्योंकि विशेष भाषाओं के लिए एमएल दृष्टिकोण कठिन क्यों होगा।

पाँचवी बारी। C, C ++, #include ।

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

हम सुझाव देते हैं कि यह उनकी लोकप्रियता / आशाजनक दृष्टिकोण के बारे में नहीं है, लेकिन यह सी और सी ++ भाषाओं के साथ समस्याओं के बारे में है। और अब हम एक असहज समस्या को प्रकाश में लाने जा रहे हैं।

एक सार सी / सीपीपी फ़ाइल को संकलित करना बहुत मुश्किल हो सकता है। कम से कम आप GitHub से किसी प्रोजेक्ट को लोड नहीं कर सकते, एक यादृच्छिक सीपीपी फ़ाइल चुनें और इसे संकलित करें। अब हम बताएंगे कि यह सब एमएल के साथ क्या करना है।

इसलिए हम विश्लेषक को पढ़ाना चाहते हैं। हमने GitHub से एक प्रोजेक्ट डाउनलोड किया। हम पैच को जानते हैं और यह मानते हैं कि यह बग को ठीक करता है। हम चाहते हैं कि यह संपादन सीखने के लिए एक उदाहरण हो। दूसरे शब्दों में, हमारे पास संपादन से पहले और बाद में एक .cpp फ़ाइल है।

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

आइए उदाहरण देखें। पहले, कोड इस तरह दिखता था:

 bool Class::IsMagicWord() { return m_name == "ML"; }

यह इस तरह से तय किया गया था:

 bool Class::IsMagicWord() { return strcmp(m_name, "ML") == 0; }

क्या विश्लेषक को सुझाव देने के लिए सीखना शुरू करना चाहिए (x == "y") प्रतिस्थापन forstrcmp (x, "y")?

वर्ग में m_name सदस्य कैसे घोषित किया जाता है, यह जाने बिना आप उस प्रश्न का उत्तर नहीं दे सकते। उदाहरण के लिए, ऐसे विकल्प हो सकते हैं:

 class Class { .... char *m_name; }; class Class { .... std::string m_name; };

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

क्लास की घोषणाएं आमतौर पर हेडर फाइलों में स्थित होती हैं। यहां सभी आवश्यक जानकारी के लिए प्रीप्रोसेसिंग करने की आवश्यकता थी। यह C और C ++ के लिए अत्यंत महत्वपूर्ण है।

यदि कोई कहता है कि यह प्रीप्रोसेसिंग के बिना करना संभव है, तो वह या तो धोखाधड़ी है, या केवल सी या + ++ भाषाओं से अपरिचित है।

सभी आवश्यक जानकारी एकत्र करने के लिए, आपको सही प्रीप्रोसेसिंग की आवश्यकता है। ऐसा करने के लिए, आपको यह जानने की आवश्यकता है कि निर्माण प्रक्रिया के दौरान मैक्रोज़ कहाँ और किस फ़ाइल पर स्थित हैं। आपको यह भी जानना होगा कि किसी विशेष cpp फ़ाइल को कैसे संकलित किया जाता है।

यही समस्या है। कोई फ़ाइल को बस संकलित नहीं करता (या, बल्कि कंपाइलर को कुंजी निर्दिष्ट करता है ताकि यह प्रीप्रोसेस फ़ाइल उत्पन्न करे)। हमें यह पता लगाने की आवश्यकता है कि यह फ़ाइल कैसे संकलित है। यह जानकारी बिल्ड स्क्रिप्ट में है, लेकिन सवाल यह है कि इसे वहां से कैसे प्राप्त किया जाए। सामान्य तौर पर, कार्य जटिल है।

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

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

सब के बाद, वर्णित समस्या बीमा योग्य नहीं है। हालांकि, यह सब बहुत कठिन और श्रम-गहन है। C और C ++ के मामले में, GitHub पर स्थित स्रोत कोड कुछ नहीं करता है। कंपाइलर्स को स्वचालित रूप से चलाने के तरीके सीखने के लिए बहुत काम किया जाना है।

नोट। यदि पाठक को अभी भी समस्या की गहराई नहीं मिलती है, तो हम आपको निम्नलिखित प्रयोग में भाग लेने के लिए आमंत्रित करते हैं। GitHub से दस-मध्य आकार की यादृच्छिक परियोजनाएं लें और उन्हें संकलित करने की कोशिश करें और फिर .cpp फ़ाइलों के लिए उनका पूर्वप्रकरणित संस्करण प्राप्त करें। उसके बाद, इस कार्य की श्रमशीलता के बारे में प्रश्न गायब हो जाएगा :)।

अन्य भाषाओं के साथ भी ऐसी ही समस्याएं हो सकती हैं, लेकिन वे C और C ++ में विशेष रूप से स्पष्ट हैं।

छठी बारी। झूठी सकारात्मकता को खत्म करने की कीमत।

स्टेटिक एनालाइज़र झूठे सकारात्मक पैदा करने के लिए प्रवण हैं और हमें झूठी चेतावनियों की संख्या को कम करने के लिए निदान को लगातार परिष्कृत करना होगा।

अब हम पहले से माने जाने वाले V789 डायग्नोस्टिक पर लौटेंगे , लूप के लिए रेंज-आधारित अंदर कंटेनर परिवर्तनों का पता लगाते हैं । मान लें कि हम इसे लिखते समय पर्याप्त सावधान नहीं थे, और ग्राहक एक झूठी सकारात्मक रिपोर्ट करता है। वह लिखता है कि कंटेनर को बदलने के बाद लूप समाप्त होने पर विश्लेषक परिदृश्य पर ध्यान नहीं देता है, और इसलिए कोई समस्या नहीं है। फिर वह कोड का निम्नलिखित उदाहरण देता है जहां विश्लेषक एक गलत सकारात्मक देता है:

 std::vector<int> numbers; .... for (int num : numbers) { if (num < 5) { numbers.push_back(0); break; // or, for example, return } }

हाँ, यह एक दोष है। एक क्लासिक विश्लेषक में, इसका उन्मूलन बेहद तेज और सस्ता है। पीवीएस-स्टूडियो में, इस अपवाद के कार्यान्वयन में कोड की 26 लाइनें शामिल हैं।

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

फिर, सवाल व्यवहार्यता में नहीं है, लेकिन व्यावहारिक दृष्टिकोण में है। हमें संदेह है कि विशिष्ट झूठे सकारात्मक के खिलाफ लड़ना, जो ग्राहकों को परेशान करता है, एमएल के मामले में कहीं अधिक महंगा है। यानी झूठी सकारात्मकता को खत्म करने के संदर्भ में ग्राहक सहायता से अधिक धन खर्च होगा।

सातवीं बारीकियाँ। शायद ही कभी इस्तेमाल की जाने वाली सुविधाएँ और लंबी पूंछ।

पहले, हम अत्यधिक विशिष्ट भाषाओं की समस्या से जूझ रहे हैं, जिसके लिए सीखने के लिए पर्याप्त स्रोत कोड नहीं हो सकता है। एक समान समस्या शायद ही कभी इस्तेमाल किए जाने वाले कार्यों (सिस्टम वाले, WinAPI, लोकप्रिय पुस्तकालयों आदि से) के साथ होती है।

यदि हम स्ट्रैम्प के रूप में सी भाषा से ऐसे कार्यों के बारे में बात कर रहे हैं, तो वास्तव में सीखने का एक आधार है। GitHub, उपलब्ध कोड परिणाम:

strcmp - 40,462,158
स्ट्रिकम्प - 1,256,053

हां, उपयोग के कई उदाहरण हैं। शायद विश्लेषक नोटिस करना सीखेंगे, उदाहरण के लिए, निम्न पैटर्न:

यह अजीब है अगर स्ट्रिंग की खुद के साथ तुलना की जाती है। यह ठीक हो जाता है।
यह अजीब है अगर संकेत देने वालों में से एक NULL है। यह ठीक हो जाता है।
यह अजीब है कि इस फ़ंक्शन के परिणाम का उपयोग नहीं किया जाता है। यह ठीक हो जाता है।
और इसी तरह।

क्या यह अच्छा नहीं है? नहीं। यहां हम "लंबी पूंछ" समस्या का सामना करते हैं। बहुत संक्षेप में निम्नलिखित में "लंबी पूंछ" का बिंदु। एक किताबों की दुकान में सबसे लोकप्रिय और अब पढ़ी जाने वाली किताबों में से Top50 को बेचना अव्यवहारिक है। हां, प्रत्येक ऐसी पुस्तक खरीदी जाएगी, जो कहती है, इस सूची की पुस्तकों की तुलना में 100 गुना अधिक है। हालाँकि, अधिकांश आय अन्य पुस्तकों से बनी होगी, जैसा कि वे कहते हैं, उनके पाठक खोजें। उदाहरण के लिए, एक ऑनलाइन स्टोर Amazon.com 130,000 "सबसे लोकप्रिय वस्तुओं" से बाहर के मुनाफे से आधे से अधिक प्राप्त करता है।

लोकप्रिय कार्य हैं और उनमें से कुछ हैं। अलोकप्रिय हैं, लेकिन उनमें से कई हैं। उदाहरण के लिए, स्ट्रिंग तुलना फ़ंक्शन के निम्नलिखित रूप हैं:

g_ascii_strncasecmp - 35,695
lstrcmpiA - 27,512
_wcsicmp_l - 5,737
_strnicmp_l - 5,848
_mbscmp_l - 2,458
और अन्य।

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

पीवीएस-स्टूडियो में, हम मैन्युअल रूप से सुविधाओं की व्याख्या करते हैं। उदाहरण के लिए, इस समय तक C और C ++ के लिए लगभग 7,200 कार्य किए गए थे। यह वह है जो हम चिह्नित करते हैं:

WinAPI
मानक सी लाइब्रेरी,
मानक टेम्प्लेट लाइब्रेरी (STL),
glibc (GNU C लाइब्रेरी)
क्यूटी
MFC
zlib
libpng
OpenSSL
और अन्य।

एक ओर, यह एक मृत-अंत तरह लगता है। आप सब कुछ एनोटेट नहीं कर सकते। दूसरी ओर, यह काम करता है।

अब यहाँ प्रश्न है। एमएल के क्या फायदे हो सकते हैं? महत्वपूर्ण फायदे स्पष्ट नहीं हैं, लेकिन आप जटिलता देख सकते हैं।

आप तर्क दे सकते हैं कि स्वयं ML पर निर्मित एल्गोरिदम अक्सर उपयोग किए जाने वाले कार्यों के साथ पैटर्न पाएंगे और उन्हें एनोटेट करने की आवश्यकता नहीं है। हाँ, यह सच है। हालांकि, ऐसे लोकप्रिय कार्यों को स्वतंत्र रूप से एनोटेक करने की कोई समस्या नहीं है जैसे कि स्ट्रैम्प या मॉलोक ।

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

उदाहरण के लिए एक फ़ंक्शन लें, जैसे कि _fread_nolock । बेशक, इसका उपयोग फ़्रेड की तुलना में कम बार किया जाता है। लेकिन जब आप इसका उपयोग करते हैं, तो आप वही गलतियाँ कर सकते हैं। उदाहरण के लिए, बफर काफी बड़ा होना चाहिए। यह आकार दूसरे और तीसरे तर्क को गुणा करने के परिणाम से कम नहीं होना चाहिए। यानी आप ऐसा गलत कोड ढूंढना चाहते हैं:

 int buffer[10]; size_t n = _fread_nolock(buffer, size_of(int), 100, stream);

इस फ़ंक्शन का एनोटेशन पीवीएस-स्टूडियो में कैसा दिखता है:

 C_"size_t _fread_nolock" "(void * _DstBuf, size_t _ElementSize, size_t _Count, FILE * _File);" ADD(HAVE_STATE | RET_SKIP | F_MODIFY_PTR_1, nullptr, nullptr, "_fread_nolock", POINTER_1, BYTE_COUNT, COUNT, POINTER_2). Add_Read(from_2_3, to_return, buf_1). Add_DataSafetyStatusRelations(0, 3);

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

अब इस फ़ंक्शन के बारे में एमएल के दृष्टिकोण से बात करते हैं। GitHub हमारी मदद नहीं करेगा। इस समारोह के लगभग 15,000 उल्लेख हैं। वहाँ भी कम अच्छा कोड है। खोज परिणामों का एक महत्वपूर्ण हिस्सा निम्नलिखित लेता है:

 #define fread_unlocked _fread_nolock

विकल्प क्या हैं?

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

जैसा कि आप देख सकते हैं, एमएल और शायद ही कभी इस्तेमाल की जाने वाली सुविधाओं की लंबी पूंछ एक साथ नहीं जाती हैं।

इस बिंदु पर, एमएल से संबंधित लोग थे जिन्होंने आपत्ति जताई और कहा कि हमने विकल्प पर ध्यान नहीं दिया था जब विश्लेषक सभी कार्यों को सीखेंगे और वे जो कर रहे थे उसका निष्कर्ष निकालेंगे। यहाँ, जाहिरा तौर पर, या तो हम विशेषज्ञों को नहीं समझते हैं, या वे हमारी बात नहीं मानते हैं।

कार्यों के निकाय अज्ञात हो सकते हैं। उदाहरण के लिए, यह एक WinAPI- संबंधित फ़ंक्शन हो सकता है। यदि यह शायद ही कभी इस्तेमाल किया जाने वाला कार्य है, तो विश्लेषक कैसे समझेंगे कि यह क्या कर रहा है? हम कल्पना कर सकते हैं कि विश्लेषक स्वयं Google का उपयोग करेगा, फ़ंक्शन का विवरण ढूंढें, इसे पढ़ें और समझें । इसके अलावा, इसे प्रलेखन से उच्च-स्तरीय निष्कर्ष निकालना होगा। _Fread_nolock विवरण बफर, दूसरे और तीसरे तर्क के बीच परस्पर संबंध के बारे में कुछ नहीं बताता है। प्रोग्रामिंग के सामान्य सिद्धांतों और C ++ भाषा कैसे काम करती है, इसकी समझ के आधार पर यह तुलना कृत्रिम बुद्धिमत्ता द्वारा की जानी चाहिए। मुझे लगता है कि हमें 20 साल में इस सब के बारे में गंभीरता से सोचना चाहिए।

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

 void *memmove (void *dest, const void *src, size_t len) { return __builtin___memmove_chk(dest, src, len, __builtin_object_size(dest, 0)); }

__Builtin___memmove_chk क्या है? यह एक आंतरिक कार्य है जिसे कंपाइलर पहले से ही लागू कर रहा है। इस फ़ंक्शन में स्रोत कोड नहीं है।

या मेम्मोव कुछ इस तरह दिख सकता है: पहला विधानसभा संस्करण । आप विभिन्न विधानसभा विकल्पों को समझने के लिए विश्लेषक को सिखा सकते हैं, लेकिन ऐसा दृष्टिकोण गलत लगता है।

ठीक है, कभी-कभी कार्यों के निकायों को वास्तव में जाना जाता है। इसके अलावा, हम उपयोगकर्ता के कोड में कार्यों के निकायों को भी जानते हैं। ऐसा लगता है कि इस मामले में एमएल को इन सभी कार्यों को पढ़ने और समझने से भारी लाभ मिलता है।

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

अन्य बारीकियां

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

Outdated recommendations. As mentioned, languages change, and recommendations for their use change, respectively. If the analyzer learns on old source code, it might start issuing outdated recommendations at some point. Example. Formerly, C++ programmers have been recommended using auto_ptr instead of half-done pointers. This smart pointer is now considered obsolete and it is recommended that you use unique_ptr .
Data models. At the very least, C and C++ languages have such a thing as a data model . This means that data types have different number of bits across platforms. If you don't take this into account, you can incorrectly teach the analyzer. For example, in Windows 32/64 the long type always has 32 bits. But in Linux, its size will vary and take 32/64 bits depending on the platform's number of bits. Without taking all this into account, the analyzer can learn to miscalculate the size of the types and structures it forms. But the types also align in different ways. All this, of course, can be taken into account. You can teach the analyzer to know about the size of the types, their alignment and mark the projects (indicate how they are building). However, all this is an additional complexity, which is not mentioned in the research articles.
Behavioral unambiguousness. Since we're talking about ML, the analysis result is more likely to have probabilistic nature. That is, sometimes the erroneous pattern will be recognized, and sometimes not, depending on how the code is written. From our experience, we know that the user is extremely irritated by the ambiguity of the analyzer's behavior. He wants to know exactly which pattern will be considered erroneous and which will not, and why. In the case of the classical analyzer developing approach, this problem is poorly expressed. Only sometimes we need to explain our clients why there is a/there is no analyzer warning and how the algorithm works, what exceptions are handled in it. Algorithms are clear and everything can always be easily explained. An example of this kind of communication: " False Positives in PVS-Studio: How Deep the Rabbit Hole Goes ". It's not clear how the described problem will be solved in the analyzers built on ML.

Conclusions

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

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

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

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

स्थैतिक विश्लेषण की कार्यप्रणाली एमएल के परिचय से लाभान्वित हो सकती है, लेकिन इस तकनीक की संभावनाओं को अतिरंजित नहीं करती है।

पुनश्च

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

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

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

आपका ध्यान के लिए धन्यवाद। हम आपको लेख पढ़ने के लिए आमंत्रित करते हैं "आपको अपनी विकास प्रक्रिया में एकीकृत करने के लिए पीवीएस-स्टूडियो स्टेटिक विश्लेषक का चयन क्यों करना चाहिए । "

प्रोग्राम सोर्स कोड के स्टेटिक विश्लेषण में मशीन लर्निंग