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

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

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

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

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

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

कुछ प्रसिद्ध उदाहरणों पर विचार करें:

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

DeepCode

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

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

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

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

तर्क करना

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

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

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

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

• सरणी से बाहर जाना;
• टाइपकास्ट अपवाद;
• असत्यापित डेटा का रिसाव;
• दौड़ की स्थिति।

SapFix

SapFix एक स्वचालित संपादन उपकरण है। यह Sapienz, एक परीक्षण स्वचालन उपकरण और Infer स्थिर विश्लेषक से जानकारी प्राप्त करता है, और नवीनतम परिवर्तनों और संदेशों के आधार पर, 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 सर्वश्रेष्ठ आचरण
• समानता
• संसाधन लीक
• गोपनीय जानकारी लीक
• कोडिंग के लिए सामान्य "सर्वश्रेष्ठ अभ्यास"

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

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

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

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

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

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

मान लें कि हम एमएल का उपयोग करना चाहते हैं ताकि विश्लेषक कोड में निम्नलिखित फॉर्म की विसंगतियों की तलाश शुरू कर दे:

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(" , !", left, 501, Level_1, "CWE-571"); } } 

और वह यह है। कोई नमूना प्रशिक्षण आधार की जरूरत है!

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

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

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

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

सामान्य तौर पर, यह वही है जो पीवीएस-स्टूडियो में लागू V530 के निदान करते हैं ।

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

पीवीएस-स्टूडियो विश्लेषक में सभी अपवादों के साथ 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 पर संपादन काफी अव्यवस्थित और विविध हैं। लोग अक्सर परमाणु कमिट करने के लिए बहुत आलसी होते हैं और एक ही बार में कोड में कई बदलाव करते हैं। आप खुद जानते हैं कि ऐसा कैसे होता है: उन्होंने त्रुटि को ठीक किया, और साथ ही साथ थोड़ा सा सुधार किया ("और यहाँ मैं एक ही समय में इस तरह के मामले के प्रसंस्करण को जोड़ दूंगा ...")। फिर भी, यह किसी व्यक्ति को स्पष्ट नहीं हो सकता है कि ये परिवर्तन एक-दूसरे से संबंधित हैं या नहीं।

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

क्या यह मार्कअप संभव है? संभव। लेकिन ध्यान दें कि परिवर्तन कितनी जल्दी होता है। "गीथहब के आधार पर एल्गोरिथ्म को सीखना" के बजाय, हम पहले से ही चर्चा कर रहे हैं कि लंबे समय तक सैकड़ों लोगों की पहेली कैसे बनाई जाए। श्रम लागत और उपकरण बनाने की लागत में तेजी से वृद्धि होती है।

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

इसलिए, हम अभी तक प्रशिक्षण तक नहीं पहुँचे हैं, लेकिन पहले से ही बारीकियाँ हैं :)।

दूसरी बारीकियाँ। विकास में अंतराल।

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

C # 8.0 ने Null Reference Exception (NREs) से निपटने में मदद करने के लिए Nullable Reference types पेश किए। JDK 12 एक नया स्विच स्टेटमेंट ( JEP 325 ) पेश करता है। C ++ 17 में, संकलन चरण ( सशर्त यदि ) पर सशर्त निर्माणों को निष्पादित करना संभव हो गया। और इसी तरह।

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

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

आइए इस समस्या को एक विशिष्ट उदाहरण के साथ देखें। लूप के लिए रेंज-आधारित 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 पुनरावृत्तियों का अमान्यकरण हो सकता है। परिणाम अपरिभाषित कार्यक्रम व्यवहार होगा।

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

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

कितने साल गुजरना चाहिए? पांच? दस?

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

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

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

सबसे अधिक संभावना है, यह 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 check(const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); } 

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

क्या करें? अंतर क्या है? क्या मुझे ऐसा प्रतिस्थापन करना चाहिए?

सिद्धांत रूप में, यहां आप एक मौका ले सकते हैं और कोड को ठीक करने के लिए सहमत हो सकते हैं। यद्यपि उन्हें समझे बिना संपादन स्वीकार करना, यह बहुत अभ्यास है ... :) आप मेम्कैंप फ़ंक्शन के विवरण को देख सकते हैं और पढ़ सकते हैं कि फ़ंक्शन int 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(); //    obj.state = 200; out.writeObject(obj); out.close(); 

ऑब्जेक्ट को बदलने और इसे फिर से रिकॉर्ड करने के बजाय, एक नई ऑब्जेक्ट बनाई जाती है और यह पहले से ही सीरीज़ की जाती है।

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

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

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

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

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

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

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

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

चौथी बारीकियाँ। अति विशिष्ट भाषाएँ।

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

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

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

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

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

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

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

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

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

हमारे पास एक परिकल्पना है कि यह लोकप्रियता / वादे की बात नहीं है, लेकिन यह है कि सी और सी ++ भाषाओं के साथ समस्याएं हैं। और अब हम समीक्षा के लिए एक असुविधाजनक समस्या को "दूर" कर देंगे।

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

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

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

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

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

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

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

क्या मुझे इस मामले के आधार पर सीखना शुरू करना चाहिए, भविष्य में मैं स्ट्रैम्प (x, "y") के साथ x (= = "y") को बदलने का सुझाव देता हूं ?

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

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

यदि हम एक साधारण सूचकांक के बारे में बात कर रहे हैं तो संपादन किया जाएगा। यदि आप चर के प्रकार को ध्यान में नहीं रखते हैं, तो आप उपयोगी चेतावनियों के साथ-साथ हानिकारक चेतावनी देना सीख सकते हैं (केस std :: string के लिए )।

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

यदि कोई कहता है कि आप प्रीप्रोसेसिंग के बिना कर सकते हैं, तो वह या तो एक चार्लटन है या बस सी या सी ++ भाषाओं से परिचित नहीं है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लोकप्रिय विशेषताएं हैं और उनमें से कुछ हैं। अलोकप्रिय हैं, लेकिन उनमें से कई हैं। उदाहरण के लिए, स्ट्रिंग तुलनात्मक कार्य की ऐसी किस्में अभी भी हैं:

• g_ascii_strncasecmp - 35,695
• lstrcmpiA - 27,512
• _wcsicmp_l - 5,737
• _strnicmp_l - 5,848
• _mbscmp_l - 2,458
• आदि

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

पीवीएस-स्टूडियो में, हम मैन्युअल रूप से फ़ंक्शन को एनोटेट करते हैं। उदाहरण के लिए, C और C ++ के लिए, वर्तमान में लगभग 7200 फ़ंक्शन लेबल हैं। अंकन इसके अधीन है:

• WinAPI
• C मानक पुस्तकालय
• मानक टेम्पलेट लाइब्रेरी (STL),
• glibc (GNU C लाइब्रेरी)
• क्यूटी
• MFC
• zlib
• libpng
• OpenSSL
• आदि

एक ओर, यह एक मृत अंत की तरह लगता है। हर चीज का सत्यानाश करना असंभव है। दूसरी ओर, यह काम करता है।

अब सवाल। एमएल के क्या लाभ हैं? महत्वपूर्ण लाभ दिखाई नहीं दे रहे हैं, लेकिन कठिनाइयां दिखाई दे रही हैं।

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

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

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

 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 

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

1. कुछ मत करो। यह कहीं भी सड़क नहीं है।
2. अकेले इस फ़ंक्शन के लिए सैकड़ों उदाहरण लिखकर विश्लेषक को प्रशिक्षित करें, ताकि विश्लेषक बफर आकार और अन्य तर्कों के बीच संबंध को समझे। हां, आप ऐसा कर सकते हैं, लेकिन यह आर्थिक रूप से तर्कहीन है। यह कहीं भी सड़क नहीं है।
3. , , . , . ML :). .

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

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

फंक्शन बॉडीज का पता नहीं चल सकता है। उदाहरण के लिए, यह एक WinAPI- संबंधित फ़ंक्शन हो सकता है। यदि यह शायद ही कभी इस्तेमाल किया जाने वाला कार्य है, तो विश्लेषक यह कैसे समझता है कि यह क्या करता है? हम कल्पना कर सकते हैं कि प्रशिक्षण के दौरान विश्लेषक स्वयं Google का उपयोग करेगा, फ़ंक्शन का विवरण ढूंढें, इसे पढ़ें और समझें । इसके अलावा, प्रलेखन से उच्च-स्तरीय निष्कर्ष निकालना आवश्यक है। _Fread_nolock के वर्णन मेंकहीं यह बफर के आकार, दूसरे और तीसरे तर्क के बीच संबंध के बारे में नहीं कहा गया है। यह तुलना कृत्रिम बुद्धि द्वारा स्वतंत्र रूप से की जानी चाहिए, यह प्रोग्रामिंग के सामान्य सिद्धांतों और सी ++ भाषा कैसे काम करती है, इसकी समझ पर आधारित है। ऐसा लगता है कि इस सब पर गंभीरता से 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 क्या है ? यह एक आंतरिक कार्य है जिसे कंपाइलर ही लागू करता है। इस फ़ंक्शन में स्रोत कोड नहीं है।

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

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

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

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

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

• . , , . , - . . C++ auto_ptr . unique_ptr .
• . , C C++ , . , . , . , long Windows 32/64 32 . Linux 32/64 . , . -. , , . , ( ). , .
• . ML, , , . यानी , — , , . , . , , — , . . , / , , , . . : " PVS-Studio: ". , , .

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

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

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

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

स्थैतिक विश्लेषण पद्धति एमएल के कार्यान्वयन से लाभान्वित हो सकती है, लेकिन इस तकनीक की क्षमताओं को बढ़ा-चढ़ाकर पेश नहीं करती है।

पुनश्च

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

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

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

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

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