MISRA क्या है और इसे कैसे पकाना है

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

हमारे कई पाठकों ने सुना है कि पीवीएस-स्टूडियो MISRA मानक के अनुसार उनके अलर्ट के वर्गीकरण का समर्थन करता है। वर्तमान में PVS-Studio में 100 से अधिक MISRA C: 2012 और MISRA C ++: 2008 नियम शामिल हैं।

इस लेख में एक पत्थर से तीन पक्षियों को मारने का लक्ष्य है:

1. बताएं कि MISRA उन लोगों के लिए है जो इस मानक से परिचित नहीं हैं;
2. हम क्या करने में सक्षम हैं की एम्बेडेड दुनिया को याद दिलाना;
3. नए कर्मचारियों के लिए व्यवसाय के पाठ्यक्रम में गहराई लाने में मदद करने के लिए जो हमारे MISRA विश्लेषक को और विकसित करेंगे;

मुझे उम्मीद है कि मैं इसे दिलचस्प बना सकता हूं। तो चलिए शुरू करते है!

MISRA कहानी

MISRA का इतिहास बहुत पहले शुरू हुआ था। फिर, 90 के दशक की शुरुआत में, संकेत नाम "सेफ आईटी" के तहत यूके सरकार के कार्यक्रम ने विभिन्न प्रणालियों के लिए धन आवंटित किया, एक तरीका या इलेक्ट्रॉनिक प्रणालियों की सुरक्षा से संबंधित एक और। MISRA (मोटर उद्योग सॉफ्टवेयर विश्वसनीयता एसोसिएशन) परियोजना की स्थापना स्वयं भूमि वाहनों में माइक्रोकंट्रोलर के लिए सॉफ्टवेयर विकसित करने के लिए एक गाइड बनाने के लिए की गई थी - कारों में, सामान्य तौर पर।

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

जब राज्य से धन समाप्त हो गया, तो MISRA के सदस्यों ने अनौपचारिक आधार पर एक साथ काम करना जारी रखने का फैसला किया - यह आज भी जारी है। वास्तव में, MISRA (एक संगठन के रूप में) विभिन्न ऑटो और विमान निर्माण उद्योगों से हितधारकों का एक समुदाय है। अब ये दल हैं:

• बेंटले मोटर कार
• फोर्ड मोटर कंपनी
• जगुआर लैंड रोवर
• डेल्फी डीजल सिस्टम
• होर्बा मिरा
• प्रोटियन विद्युत
• विस्टोन इंजीनियरिंग सेवाएं
• यूनिवर्सिटी ऑफ लेड्स
• रिकार्डो ब्रिटेन
• ZF TRW

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

दर्शन और नियमों के उदाहरण

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

गंभीरता की सीमा को समझने के लिए, मानक से लिए गए कुछ नियमों पर विचार करें।

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

• एक uninitialized चर के मान का उपयोग न करें
• स्ट्रीम बंद करने के बाद FILE पॉइंटर का उपयोग न करें
• सभी गैर-शून्य फ़ंक्शन को एक मान वापस करना होगा।
• लूप काउंटर में फ्लोटिंग-पॉइंट प्रकार नहीं होना चाहिए
• ... आदि।

दूसरी ओर, नियम हैं, जिनके लाभ सतह पर हैं, लेकिन जो (सामान्य परियोजनाओं के दृष्टिकोण से) तोड़ने के लिए इतने पापी नहीं हैं:

• गोटो और लॉन्गजम्प का उपयोग न करें
• प्रत्येक स्विच को डिफ़ॉल्ट रूप से समाप्त होना चाहिए
• अगम्य कोड न लिखें
• चर कार्यों का उपयोग न करें
• पता अंकगणित ( [] और ++ को छोड़कर) का उपयोग न करें
• ...

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

हम नहीं चाहते हैं, एक सॉफ्टवेयर त्रुटि के कारण, कुछ एक्स-रे मशीन ने 20,000 रेड की खुराक के साथ रोगियों को विकिरणित किया है , इसलिए सामान्य "रोज़" नियम अब पर्याप्त नहीं हैं। दांव पर मानव जीवन और बड़ी मात्रा में पैसे हैं, और सावधानी को शामिल किया जाना चाहिए। यहाँ MISRA के बाकी नियम स्टेज पर हैं:

• शाब्दिक में प्रत्यय 'L' हमेशा अपरकेस होना चाहिए (छोटा 'l' यूनिट से भ्रमित हो सकता है)
• अल्पविराम ऑपरेटर का उपयोग न करें (यह गलती करने की संभावना को बढ़ाता है)
• पुनरावृत्ति का उपयोग न करें (एक छोटा माइक्रोकंट्रोलर स्टैक आसानी से बह सकता है)
• यदि , के, के लिए , जबकि , करते हैं , स्विच स्टेटमेंट को घुंघराले ब्रेसिज़ में लपेटा जाना चाहिए (यदि कोड सही तरीके से कोड संरेखित नहीं किया गया है तो आप संभवतः गलती कर सकते हैं)
• गतिशील मेमोरी का उपयोग न करें (क्योंकि ढेर से इसे आवंटित करने का असफल मौका है, विशेष रूप से माइक्रोकंट्रोलर में)
• ... और कई, ऐसे कई नियम।

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

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

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

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

और क्या है

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

सबसे पहले, मानक में पृष्ठभूमि के बजाय पूरी तरह से विवरण होता है: मानक क्या बनाया गया था, इसके लिए सी या सी ++ क्यों चुना गया, इन भाषाओं के फायदे और नुकसान।

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

for (int i = 0; i < n; ++i); { do_something(); } 

फिर भी, एक मौका है कि एक व्यक्ति एक अतिरिक्त अर्धविराम को नोटिस नहीं करेगा, है ना? आप इस तरह भी लिख सकते हैं:

 void SpendTime(bool doWantToKillPeople) { if (doWantToKillPeople = true) { StartNuclearWar(); } else { PlayComputerGames(); } } 

यह अच्छा है कि पहले और दूसरे मामले दोनों को आसानी से MISRA नियमों द्वारा पकड़ा जाता है (पहला MISRA C: 13.4 / MISRA C ++: 6.2.1 है, दूसरा MISRA C: 13.4 / MISRA C ++: 6.2.1 है)।

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

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

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

अपनी परियोजनाओं में उपयोग करें

एक स्थिति की कल्पना करें: आप कुछ बहुत ही आवश्यक और जिम्मेदार एम्बेडेड सिस्टम के लिए एक कार्यक्रम लिखने जा रहे हैं। या आपके पास पहले से ही एक कार्यक्रम है, लेकिन आपको इसे MISRA में "ट्रांसफर" करने की आवश्यकता है। मानक के अनुपालन के लिए अपने कोड की जांच कैसे करें? क्या आपको वास्तव में इसे मैन्युअल रूप से करना है?

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

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

अगला प्रश्न: आप MISRA का उपयोग किस बिंदु पर शुरू करते हैं? इसका उत्तर सरल है: जितनी जल्दी बेहतर हो। आदर्श रूप से, इससे पहले कि आप कोड लिखना भी शुरू कर दें, क्योंकि MISRA मानता है कि आप अपने कोड के जीवन भर मानक का पालन करते हैं।

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

यह वह जगह है जहाँ पिटफुल पॉप अप होता है। मैं भी एक पानी के नीचे बोल्डर चबूतरे कहना होगा। यदि आप एक स्थिर विश्लेषक लेते हैं और MISRA मानक के अनुपालन के लिए "साधारण" परियोजना की जांच करते हैं तो क्या होता है? Spoiler: आप डर सकते हैं।

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

इसके बारे में क्या करना है? क्या सभी चीजों को अलग रखना और सभी पुरानी सकारात्मकताओं को ठीक करने के लिए बैठना वास्तव में आवश्यक है?

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

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

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

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

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

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

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

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

मानक के अनुपालन का दावा करने के लिए, आपको कुछ चीजों की आवश्यकता होगी:

• वास्तव में एक परियोजना जिसका कोड अनिवार्य और आवश्यक नियमों का अनुपालन करता है
• गाइड प्रवर्तन योजना
• सभी संकलक और स्थिर विश्लेषक चेतावनी का दस्तावेजीकरण
• आवश्यक नियमों से सभी विचलन का दस्तावेजीकरण
• दिशानिर्देश अनुपालन सारांश

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

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

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

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

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

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

यदि आप नियम से विचलित करने का निर्णय लेते हैं, तो दस्तावेज में होना चाहिए:

• टूटा हुआ नियम संख्या
• सटीक विचलन स्थान
• विचलन की वैधता
• सबूत है कि विचलन सुरक्षा से समझौता नहीं करता है
• संभावित उपयोगकर्ता निहितार्थ

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

अब नियमों के अनुपालन के सारांश के बारे में। इस पेपर को भरना शायद सबसे आसान है:

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

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

अंतिम कॉलम के साथ, सब कुछ सरल है: यह ध्यान देना पर्याप्त है कि क्या नियम का उपयोग किया जाता है, और यदि ऐसा है, तो इसके लिए विचलन हैं।

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

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

अब आपका कार्यक्रम कहाँ पर रहेगा? MRI मशीन में? एक साधारण गति सेंसर में या कुछ अंतरिक्ष उपग्रह के ऑटोपायलट सिस्टम में? हां, आप एक गंभीर नौकरशाही मार्ग से गुजरे हैं, लेकिन ये त्रिपाल हैं। जब वास्तविक मानव जीवन दांव पर लगा हो, तो कोई कैसे सावधानी नहीं बरत सकता?

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

मानकों का भविष्य

अंत में, मैं मानकों के भविष्य के बारे में थोड़ी बात करना चाहता हूं।

MISRA वर्तमान में रह रहा है और विकसित हो रहा है। उदाहरण के लिए, 2019 की शुरुआत में, "MISRA C: 2012 थर्ड एडिशन (फर्स्ट रिवीजन)" की घोषणा की गई - नए नियमों 2012 के मानक द्वारा अद्यतन और पूरक। इसी समय, उन्होंने MISRA C: 2012 संशोधन 2 - C11 Core, 2012 मानक की आगामी रिलीज की घोषणा की, जो पहली बार 2011 सी और सी संस्करणों को कवर करने वाले नियमों को जोड़ देगा।

अभी भी खड़ा नहीं है और MISRA C ++। जैसा कि आप जानते हैं, नवीनतम MISRA C ++ मानक 2008 से पहले का है, इसलिए इसे कवर करने वाली भाषा का सबसे पुराना संस्करण C ++ 03 है। इस वजह से, MISRA के समान एक और मानक है, और इसे AUTOSAR C ++ कहा जाता है। यह मूल रूप से MISRA C ++ की निरंतरता के रूप में कल्पना की गई थी और भाषा के बाद के संस्करणों को कवर करने का इरादा था। इसके मास्टरमाइंड के विपरीत, AUTOSAR C ++ को वर्ष में दो बार अपडेट किया जाता है और वर्तमान में C ++ 14 का समर्थन करता है। आगे के उन्नयन की योजना C ++ 17, और फिर C ++ 20, और इसी तरह की है।

मैंने कुछ अन्य मानक के बारे में क्या शुरू किया? तथ्य यह है कि एक साल पहले की तुलना में थोड़ा कम, दोनों संगठनों ने एक में अपने मानकों के एकीकरण की घोषणा की। अब MISRA C ++ और AUTOSAR C ++ एक एकल मानक बन जाएगा, और अब उन्हें एक साथ विकसित किया जाएगा। मुझे लगता है कि यह डेवलपर्स के लिए C ++ माइक्रोकंट्रोलर के तहत लिखने के लिए बहुत अच्छी खबर है, और स्थैतिक विश्लेषक के डेवलपर्स के लिए कोई कम बड़ी खबर नहीं है। आगे अभी भी बहुत सारे पसंदीदा काम है! :)

निष्कर्ष

आज हमने MISRA के बारे में बहुत कुछ सीखा है: हमने इसकी घटना का इतिहास पढ़ा, नियमों के उदाहरण और मानक के दर्शन का अध्ययन किया, माना कि आपको अपनी परियोजनाओं में MISRA का उपयोग करने की आवश्यकता है, और यहां तक ​​कि भविष्य में भी थोड़ा सा देखा। मुझे उम्मीद है कि अब आप बेहतर ढंग से समझ गए होंगे कि MISRA क्या है और इसे कैसे पकाना है!

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

यह मेरा लेख समाप्त करता है। मैं सभी पाठकों को नए साल की शुभकामनाएं देता हूं और नए साल की शुभकामनाएं देता हूं!

संबंधित लिंक

1. जार्ज ग्रिबकोव - " अधिकतम गति पर सुरक्षा - एम्बेडेड सिस्टम के लिए विश्वसनीय सी / सी ++ कोड कैसे लिखें ।"
2. PVS-Studio एक स्थिर कोड विश्लेषक है ।
3. पीवीएस-स्टूडियो और केईएल 5 सहयोग ।

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