स्थैतिक विश्लेषण और नियमित अभिव्यक्तियाँ

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



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



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





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



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

निदान ०

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

  #line 27 "C: \\ प्रोग्राम फाइल्स (x86) \\ Microsoft विज़ुअल स्टूडियो 8 \\ VC \\ atlmfc \\ शामिल \\ afx.h"
 # पंक्ति 1008 "। \\ mytestfile.cpp" 

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



कुल मिलाकर, हमने अभी तक मामले के सार को नहीं जाना है, लेकिन पहले से ही कठिनाइयों का एक समूह प्राप्त कर लिया है।

निदान 1

V501। बाईं ओर और 'फू' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं।



लेख के पाठ को अव्यवस्थित नहीं करने के लिए, मैं पाठक को लिंक का अनुसरण करने और त्रुटि और उदाहरणों के विवरण से परिचित होने का सुझाव देता हूं। निदान का सार रूप की संरचना की पहचान करना है:

  अगर (X> 0 && X> 0) 

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

  यदि (A == A && B) 

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

  अगर (A == 0 && A == 0) 

और इसलिए विभिन्न प्राथमिकताओं के साथ सभी प्रकार के संचालन के लिए तर्क प्रदान करना आवश्यक है। हां, जिस तरह से कोई भी ब्रैकेट पर भरोसा नहीं कर सकता है। ऐसे मामले हो सकते हैं:

  यदि ('(' == A && '(' == B)
 b = X> 0 && X> 0; 

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



अब उस लालित्य के साथ तुलना करें जिसके साथ मैं इस त्रुटि का पता लगा सकता हूं, एक वाक्यविन्यास वृक्ष। अगर मुझे ऑपरेटर &&, ==, || और इसी तरह, मुझे बस पेड़ की बाईं और दाईं शाखाओं की तुलना करनी है। मैं इसे इस तरह से करता हूं:

  अगर (समान (बाएं, दाएं))
 {
   // मुसीबत!
 } 

और वह यह है। परिचालन प्राथमिकताओं के बारे में सोचने की जरूरत नहीं है। आपको एक पकड़ने की उम्मीद नहीं करनी चाहिए कि पाठ में एक ब्रैकेट होगा: b = '(' == x && x == ')'। आप बस पेड़ की बाईं और दाईं शाखाओं की तुलना कर सकते हैं।

निदान २

V502। शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' संचालक की 'फू' संचालक की तुलना में कम प्राथमिकता है।



नियम संचालन की प्राथमिकता के बारे में भ्रम की स्थिति में है (विवरण के लिए त्रुटि विवरण देखें)। हमें कुछ इस तरह की पहचान करने की आवश्यकता है:

  int a;
 बूल b;
 int c = a + b?  0: 1; 

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



प्रत्येक चर के प्रकार को कम करना (विस्तार करना) आवश्यक है। आपको टाइपडेफ के जंगल से गुजरने में सक्षम होना चाहिए। आपको यह समझने के लिए कक्षाओं में देखने की आवश्यकता है कि वेक्टर <int> :: size_type क्या है। आपको नाम स्थान std का उपयोग करते हुए स्कोप और भिन्न को ध्यान में रखने की आवश्यकता है; और यहां तक ​​कि एक्स के प्रकार को एक्सप्रेशन से कम करने में सक्षम हो सकते हैं: "ऑटो एक्स = 1 + 2;" सी ++ 0x के मामले में।



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



निचला रेखा: C / C ++ प्रोग्राम के साथ नियमित अभिव्यक्तियों पर काम करना, हम चर और अभिव्यक्तियों के प्रकार को नहीं जानते हैं। याद रखें यह एक महत्वपूर्ण सीमा है।

निदान 3

V503। यह एक निरर्थक तुलना है: सूचक <0।



एक बहुत ही सरल नियम। संदेहास्पद रूप से एक सूचक की तुलना <,> शून्य से करें। एक उदाहरण:

  CMeshBase * pMeshBase = getCutMesh (Idx);
 अगर (pMeshBase <0)
   वापसी NULL; 

त्रुटि विवरण में ऐसा कोड कैसे प्राप्त किया जा सकता है।



डायग्नोस्टिक्स के लिए, आपको बस चर pMeshBase के प्रकार को जानना होगा। और यह असंभव क्यों था, यह थोड़ा अधिक बताया गया।



यह निदान नियमित अभिव्यक्तियों के आधार पर संभव नहीं है।

निदान ४

V504। यह अत्यधिक संभावना है कि अर्धविराम ';' 'वापसी' कीवर्ड के बाद गायब है।

  शून्य Foo2 (int * ptr)
 {
   अगर (ptr == NULL)
     वापसी
   फू ();
   ...
 } 

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

  int foo ()
 {
    ...
   char c [] = 
   "शून्य myFoo (इंट x) {"
   ;
   ...
 } 

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

  SimpleType funcReturnType;
 EFunctionReturnType fType;
 if (env-> LookupFunctionReturnType (fType, funcReturnType))
   वापसी;
 अगर (funcReturnType! = ST_VOID)
   वापसी; 

निदान 5

V505। लूप के अंदर 'एलोका' फ़ंक्शन का उपयोग किया जाता है। यह जल्दी से अतिप्रवाह ढेर हो सकता है।



हां, आप नियमित अभिव्यक्तियों के आधार पर इस नियम को लागू करने का प्रयास कर सकते हैं।



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

  {
   for (int i = 0; मैं <10; i ++)
   {
     // शांत टिप्पणी।  यहाँ आप {- अब पीड़ित हैं।  :)
     char * x = "यहां भी, आपको अपने कान को तेज रखने की आवश्यकता है: - {";
   }
   p = _alloca (10);  // क्या हम पाश के अंदर हैं या नहीं?
 } 

निदान ६

V506। स्थानीय चर 'X' की ओर संकेत इस चर के दायरे से बाहर संग्रहीत है। ऐसा पॉइंटर अमान्य हो जाएगा।



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



यह निदान नियमित अभिव्यक्तियों के आधार पर संभव नहीं है।

निदान 7

V507। पॉइंटर से लेकर लोकल एरे 'X' तक इस एरे के दायरे से बाहर स्टोर किए जाते हैं। ऐसा पॉइंटर अमान्य हो जाएगा।



यह निदान नियमित अभिव्यक्तियों के आधार पर संभव नहीं है।

निदान 8

V508। 'नए प्रकार (n)' पैटर्न के उपयोग का पता चला था। शायद इसका मतलब है: 'नया प्रकार [एन]'।



टाइपो खोजने के लिए उपयोगी है जैसे:

  फ्लोट * पी = नया फ्लोट (10); 

ऐसा लगता है कि सब कुछ सरल है और इसे लागू किया जा सकता है यदि हम जानते हैं कि किस प्रकार की वस्तु बनाई जा रही है। काम नहीं करेगा। बस पाठ को थोड़ा बदलें और नियमित अभिव्यक्ति बेकार है:

  टाइपराइफ फ्लोट MyReal;
 ...
 MyReal * p = new MyReal (10); 

यह निदान नियमित अभिव्यक्तियों के आधार पर संभव नहीं है।

निदान 9

V509। विध्वंसक के अंदर 'थ्रो' ऑपरेटर को कोशिश..चेक ब्लॉक के भीतर रखा जाना चाहिए। विध्वंसक के अंदर अपवाद उठाना अवैध है।



हां, आप इसे नियमित अभिव्यक्तियों पर करने की कोशिश कर सकते हैं। विध्वंसक आमतौर पर छोटे कार्य होते हैं और विभिन्न घुंघराले ब्रेसिज़ के साथ कोई चाल नहीं होगी।



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



लेकिन मैं नहीं इसी तरह से मैंने पीवीएस-स्टूडियो (पूरे नियम) में सुरुचिपूर्ण ढंग से लिखा है:

  शून्य ApplyRuleG_509 (VivaWalker और वाकर, पर्यावरण * env,
   const Ptree * srcPtree)
 {
   सिंपल टाइप रिटर्न;
   EFunctionReturnType fType;
   बूल रेस = env-> लुकअपफैक्शन रीटर्न टाइप (fType, returnType);
   अगर (res == false || returnType! = ST_UNKNOWN)
     वापसी;
   अगर (fType! = DESTRUCTOR)
     वापसी;

   ptrdiff_t tryLevel = OmpUtil :: GetLevel_TRY (env);
   अगर (tryLevel! = -1)
     वापसी;
   string error = VivaErrors :: V509 ();
   walker.AddError (त्रुटि, srcPtree, 509, DATE_1_SEP_2010 (), Level_1);
 }

डायग्नोस्टिक्स 10

V510। 'फू' फ़ंक्शन को 'एन' वास्तविक तर्क के रूप में वर्ग-प्रकार के चर प्राप्त करने की उम्मीद नहीं है।



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

निष्कर्ष

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