🔩 🙅 #⃣ मिश्रा क्या है और इसे कैसे पकाना है 🍻 🧕 🖐🏽

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

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

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

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

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

मिश्रा का इतिहास

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

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

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

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

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

मुख्य अवधारणा और नियमों के उदाहरण

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

गंभीरता के पैमाने को समझने के लिए, आइए मानक से लिए गए कुछ नियमों को देखें।

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

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

दूसरी ओर, ऐसे नियम हैं, जिनके लाभों को गिराना मुश्किल नहीं है, लेकिन जो (सामान्य परियोजनाओं के दृष्टिकोण से) कभी-कभी उल्लंघन किया जा सकता है:

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

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

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

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

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

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

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

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

अन्य मुद्दे

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

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

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

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

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

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

यह अच्छा है कि पहले और दूसरे दोनों मामलों को MISRA (1 - MISRA C: 13.4 / MISRA C ++: 6.2.1; 2 - 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 C: 2012 तीसरा संस्करण (पहला संशोधन)" 2019 की शुरुआत में घोषित नए नियमों के संस्करण के साथ एक संशोधित और बढ़े हुए है। एक ही समय में, "MISRA C: 2012 संशोधन 2 - C11 की आगामी रिलीज कोर ”, जो 2012 वर्ष का संशोधित मानक है, की घोषणा की गई थी। इस दस्तावेज़ में ऐसे नियम शामिल होंगे जो पहली बार 2011 और 2018 वर्षों के C भाषा संस्करणों को कवर करेंगे।

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

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

मिश्रा क्या है और इसे कैसे पकाना है