ما هي ميسرا وكيف تطبخها

ربما سمع كل مطور برنامج متحكم دقيق حول معايير الترميز الخاصة للمساعدة في تحسين أمان الرمز وإمكانية نقله. أحد هذه المعايير هو MISRA. في هذه المقالة ، سوف نلقي نظرة فاحصة على ما هو هذا المعيار ، مفهومه وكيفية استخدامه في مشاريعك.

لقد سمع العديد من قرائنا أن PVS-Studio يدعم تصنيف تحذيراته وفقًا لمعايير MISRA. في الوقت الحالي ، يغطي PVS-Studio أكثر من 100 من قواعد MISRA C: 2012 و MISRA C ++: 2008.

يهدف هذا المقال إلى قتل ثلاثة طيور بحجر واحد:

1. أخبر ميسرا لأولئك الذين ليسوا على دراية بهذا المعيار ؛
2. ذكّر العالم بالتطور المضمن لما يمكننا القيام به ؛
3. ساعد الموظفين الجدد لشركتنا ، الذين سيقومون أيضًا بتطوير محلل MISRA الخاص بنا في المستقبل ، على التعرف بشكل كامل عليه.

آمل أن أتمكن من جعلها مثيرة للاهتمام. لذلك دعونا نذهب!

تاريخ ميسرة

بدأ تاريخ MISRA منذ وقت طويل. في ذلك الوقت في أوائل التسعينيات ، قدم برنامج الحكومة الآمنة "IT Safe" في المملكة المتحدة التمويل لمشاريع مختلفة مرتبطة بطريقة أو بأخرى بأمن الأنظمة الإلكترونية. تم تأسيس مشروع MISRA (جمعية موثوقية صناعة البرمجيات للمحركات) نفسه لإنشاء دليل لتطوير برامج ميكروكنترولر في المركبات الأرضية - في السيارات ، في الغالب.

بعد تلقي التمويل من الدولة ، تولى فريق MISRA العمل ، وبحلول نوفمبر 1994 أصدر أول دليل له: " مبادئ توجيهية لتطوير البرمجيات المعتمدة على المركبات ". لم يتم ربط هذا الدليل بلغة معينة حتى الآن ، لكن يجب أن أعترف أن العمل قد أُنجز بشكل مثير للإعجاب وأنه يتعلق ، على الأرجح ، بجميع الجوانب التي يمكن تصورها لتطوير البرمجيات المدمجة. بالمناسبة ، احتفل مطورو هذا الدليل مؤخرًا بالذكرى 25 لمثل هذا التاريخ المهم بالنسبة لهم.

عندما انتهى التمويل المقدم من الدولة ، قرر أعضاء MISRA مواصلة العمل معًا على أساس غير رسمي ، حيث يستمر حتى يومنا هذا. بشكل عام ، MISRA (كمؤسسة) هو مجتمع من أصحاب المصلحة من مختلف صناعة السيارات والطائرات. الآن هذه الأحزاب هي:

• بنتلي موتور السيارات
• شركة فورد للسيارات
• جاكوار لاند روفر
• أنظمة الديزل دلفي
• هوريبا ميرا
• بروتيان الكهربائية
• الخدمات الهندسية Visteon
• جامعة ليدز
• ريكاردو المملكة المتحدة
• ZF TRW

لاعبين قويين في السوق ، أليس كذلك؟ ليس من المستغرب ، أن معيارهم الأول المتعلق باللغة ، MISRA C ، أصبح شائعًا بين مطوري الأنظمة المضمنة الحيوية. بعد ذلك بقليل ، ظهر MISRA C ++. تدريجيا ، تم تحديث إصدارات المعايير وتحسينها لتغطية الميزات الجديدة للغات. حتى كتابة هذه السطور ، الإصدارات الحالية هي MISRA C: 2012 و MISRA C ++: 2008.

المفهوم الرئيسي وأمثلة من القواعد

أهم ميزات MISRA هي اهتمامها المذهل بالتفاصيل والدقة الشديدة في ضمان السلامة والأمن. لم يقتصر الأمر على قيام المؤلفين بجمع كل أوجه القصور في C و C ++ في مكان واحد (على سبيل المثال ، مؤلفو CERT) - بل قاموا أيضًا بعناية بوضع المعايير الدولية لهذه اللغات وكتبوا أي طرق وكل الطرق لارتكاب خطأ. بعد ذلك ، قاموا بإضافة قواعد حول إمكانية قراءة التعليمات البرمجية لضمان رمز نظيف ضد خطأ جديد.

لفهم حجم الخطورة ، دعنا ننظر إلى بعض القواعد المأخوذة من المعيار.

من ناحية ، هناك قواعد جيدة وجديرة بالاهتمام يجب اتباعها دائمًا ، بغض النظر عن الغرض من مشروعك. بالنسبة للجزء الأكبر ، فهي مصممة للقضاء على سلوك غير محدد / غير محدد / المعرفة بالتنفيذ. على سبيل المثال:

• لا تستخدم قيمة متغير غير مهيأ
• لا تستخدم المؤشر إلى FILE بعد إغلاق الدفق
• يجب أن ترجع جميع الوظائف غير الخالية قيمة
• يجب ألا تكون عدادات الحلقة من نوع الفاصلة العائمة
• وغيرها.

من ناحية أخرى ، هناك قواعد ، والتي من الصعب إبطال فوائدها ، ولكن (من وجهة نظر المشاريع العادية) يمكن انتهاكها من حين لآخر:

• لا تستخدم goto و longjmp
• يجب أن ينتهي كل مفتاح بالتسمية الافتراضية
• لا تكتب رمز غير قابل للوصول
• لا تستخدم وظائف varadic
• لا تستخدم حساب العناوين (باستثناء [] و ++ )
• ...

مثل هذه القواعد ليست سيئة أيضًا ، وبالاقتران مع القواعد السابقة ، فإنها تعطي بالفعل زيادة ملموسة للأمان ، ولكن هل هذا يكفي للأنظمة المضمنة التي يمكن الاعتماد عليها بدرجة كبيرة؟ فهي لا تستخدم فقط في صناعة السيارات ، ولكن أيضًا في صناعات الطيران والفضاء والعسكرية والطب.

لا نريد أن يقوم جهاز الأشعة السينية بإشعاع المرضى بجرعة 20.000 راد بسبب خطأ في البرنامج ، وبالتالي فإن القواعد "اليومية" المعتادة ليست كافية. مع وجود حياة بشرية وأموال كبيرة على المحك ، لا غنى عن الدقة. إليكم ما تبقى من قواعد MISRA:

• يجب أن تكون اللاحقة "L" في الحرفي دائمًا كبيرة (يمكن خلط الأحرف الصغيرة "l" مع 1)
• لا تستخدم عامل التشغيل "فاصلة" (لأنه يزيد من فرصة ارتكاب خطأ)
• لا تستخدم العودية (مكدس متحكم صغير يمكن أن يفيض بسهولة)
• يجب أن يتم تغليف نصوص العبارات إذا كان هناك مفتاح آخر لفصل بين قوسين مجعدين (من المحتمل أنه يمكنك ارتكاب خطأ عندما تتم محاذاة الرمز بشكل غير صحيح )
• لا تستخدم الذاكرة الديناميكية (نظرًا لوجود فرصة لعدم إطلاقها من الكومة ، وخاصة في المتحكمات الدقيقة)
• ... والكثير والكثير من هذه القواعد.

يحدث ذلك غالبًا ، يكون لدى الأشخاص الذين واجهوا MISRA أولاً انطباع بأن الغرض من المعيار هو "حظر هذا وحظر ذلك". في الواقع ، الأمر كذلك ، ولكن إلى حد ما.

من ناحية ، يحتوي المعيار على العديد من هذه القواعد ، لكن لا يُقصد به حظر كل شيء ، لكن من ناحية أخرى ، فإنه يسرد schmer جميع طرق انتهاك أمان الشفرة بطريقة أو بأخرى. بالنسبة لمعظم القواعد ، يمكنك اختيار ما إذا كنت تريد متابعتها أم لا. ساوضح هذه القضية بمزيد من التفصيل.

في 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؟ المفسد: قد تكون خائفا.

صحيح ، المثال في الصورة مبالغ فيه. إنه يُظهر نتيجة فحص مشروع كبير جدًا لم يكن يعني في الواقع العمل على المتحكمات الدقيقة. ومع ذلك ، عند التحقق من الكود الموجود بالفعل ، قد تحصل على تحذير واحد أو اثنين أو ثلاثة أو حتى عشرة آلاف محلل. سوف تضيع التحذيرات الجديدة ، الصادرة للرمز الجديد أو المعدل ، في هذه المجموعة الكبيرة من التحذيرات.

إذن ماذا يمكنك أن تفعل حيال ذلك؟ هل يجب عليك تأجيل جميع المهام والبدء في إصلاح التحذيرات القديمة؟

كمطورين للمحلل الثابت ، نعلم أن الكثير من التحذيرات تظهر بعد الفحص. لذلك ، قمنا بتطوير الحل ، والذي يمكن أن يساعد في الاستفادة من المحلل على الفور دون إيقاف العمل. هذا الحل يسمى "قاعدة قمع".

تمثل قواعد كبح آلية PVS-Studio التي تسمح لك لقمع رسائل محلل على نطاق واسع. إذا قمت بفحص مشروع لأول مرة وحصلت على عدة آلاف من التحذيرات - فستحتاج فقط إلى إضافتها في قاعدة قمع ولن يمنحك التشغيل التالي أية تحذيرات.

وبهذه الطريقة ، يمكنك الاستمرار في كتابة التعليمات البرمجية وتغييرها كالمعتاد ، وعند القيام بذلك ، سوف تحصل على رسائل فقط حول الأخطاء التي تم إجراؤها للتو في المشروع. لذلك سوف تحصل على أقصى استفادة من المحلل هنا والآن ، دون أن تصرف انتباهك عن طريق خداع الأخطاء القديمة. عدد قليل من النقرات - واعتمد محلل في التنمية الخاصة بك! يمكنك قراءة التعليمات المفصلة حول القيام بذلك هنا .

ربما تتساءل: "انتظر ، ماذا عن التحذيرات الخفية؟" الإجابة بسيطة للغاية: لا تنسَها وتصلحها على مراحل سهلة. على سبيل المثال ، يمكنك تحميل قاعدة الإيقاف في نظام التحكم في الإصدار والسماح فقط لتلك الأوامر التي لا تزيد عدد التحذيرات. وهكذا ، تدريجياً "الصخرة تحت الماء" سوف تطحن عاجلاً أو آجلاً دون ترك أي أثر.

حسنًا ، لقد تم اعتماد المحلل بنجاح الآن ونحن مستعدون للمتابعة. ماذا تفعل بعد ذلك؟ الجواب بديهي - العمل مع الكود! ولكن ما الذي يتطلبه الأمر لكي تكون قادرًا على إعلان الامتثال للمعايير؟ كيف تثبت أن مشروعك يتوافق مع MISRA؟

في الواقع ، لا توجد "شهادة" خاصة بأن رمزك يتوافق مع MISRA. كما ينص المعيار ، يجب أن يتم تتبع الامتثال من قبل طرفين: عميل البرنامج ومورد البرنامج. يقوم البائع بتطوير برنامج يفي بالمعايير ويملأ المستندات اللازمة. يجب على العميل ، بدوره ، التأكد من صحة البيانات الواردة من هذه المستندات.

إذا قمت بتطوير برنامج خاص بك ، فستتحمل مسؤولية الوفاء بالمعيار فقط على كتفيك :)

بشكل عام ، لإثبات امتثال مشروعك ، ستحتاج إلى مستندات داعمة. قد تختلف قائمة الوثائق التي يجب على مطوري المشروع إعدادها ، لكن MISRA تقدم مجموعة معينة كمرجع. دعونا نلقي نظرة فاحصة على هذه المجموعة.

ستحتاج إلى هذه الأشياء للتقدم بطلب التوافق القياسي:

• المشروع نفسه ، الذي يتوافق مع قواعده الإلزامية والقواعد المطلوبة
• توجيه خطة التنفيذ
• الوثائق على جميع التحذيرات مترجم ومحلل ثابت
• وثائق لجميع الانحرافات عن القواعد المطلوبة
• ملخص الامتثال التوجيهي

الأول هو خطة إنفاذ الدليل. هذا هو الجدول الأكثر أهمية ، ويحتوي على مراجع لجميع المستندات الأخرى. في العمود الأول هو قائمة قواعد MISRA ، في الباقي ، يلاحظ ما إذا كان هناك أي انحراف عن تلك القواعد. هذا الجدول يبدو كالتالي:

يوصي المعيار ببناء مشروعك مع العديد من المجمعين ، وكذلك استخدام اثنين أو أكثر من أجهزة التحليل الثابتة لاختبار الكود الخاص بك للتأكد من توافقه. إذا أصدر المحول البرمجي أو المحلل تحذيراً يتعلق بالقواعد ، فيجب أن تلاحظه في الجدول وتوثيق النقاط التالية: لماذا لا يمكن إصلاح التحذير ، سواء كان خطأ أم لا ، إلخ.

إذا تعذر التحقق من إحدى القواعد بواسطة محلل ثابت ، فيجب عليك مراجعة التعليمات البرمجية اليدوية. يجب أيضًا توثيق هذا الإجراء ، وبعد ذلك يجب إضافة رابط لهذه الوثائق إلى خطة الامتثال.

إذا تبين أن المحول البرمجي أو المحلل الثابت صحيح ، أو إذا كانت هناك انتهاكات صحيحة للقواعد أثناء عملية مراجعة التعليمات البرمجية ، فيجب عليك إما تصحيحها أو توثيقها. مرة أخرى ، عن طريق إرفاق الرابط بالوثائق في الجدول.

وبالتالي ، فإن خطة الامتثال عبارة عن مستند يوفر الوثائق لأي انحراف محدد في التعليمات البرمجية الخاصة بك.

دعونا نتطرق بإيجاز إلى التوثيق المباشر للانحرافات عن القواعد. كما ذكرت ، هذه الوثائق ضرورية فقط للقواعد المطلوبة ، لأنه لا يمكن انتهاك القواعد الإلزامية ، ويمكن انتهاك القواعد الاستشارية دون أي وثائق.

إذا اخترت الخروج عن القاعدة ، فيجب أن تتضمن الوثائق:

• عدد القاعدة المخالفة
• الموقع الدقيق للانحراف
• صحة الانحراف
• دليل على أن الانحراف لا يضر بالأمن
• عواقب محتملة للمستخدم

كما ترون ، فإن هذا النهج في التوثيق يجعلك تتساءل بجدية عما إذا كان الانتهاك يستحق ذلك. تم ذلك على وجه التحديد لعدم الشعور بأي رغبة في انتهاك القواعد المطلوبة :)

الآن عن ملخص الامتثال للقواعد. ربما تكون هذه الورقة هي الأسهل لملءها:

يتم ملء العمود المركزي قبل البدء في العمل باستخدام الكود ، والعمود الصحيح - بعد أن يكون مشروعك جاهزًا.

إليك سؤال معقول: لماذا يجب تحديد فئات القواعد ، إذا كانت محددة بالفعل في المعيار نفسه؟ والحقيقة هي أن المعيار يسمح "بالترويج" لقاعدة في فئة أكثر صرامة. على سبيل المثال ، قد يطلب منك أحد العملاء تصنيف قاعدة استشارية. يجب إجراء هذا "الترويج" قبل التعامل مع الكود ، ويسمح لك ملخص الامتثال للقواعد بتدوينه بوضوح.

بالنسبة إلى العمود الأخير ، الأمر بسيط جدًا: تحتاج فقط إلى ملاحظة ما إذا كان يتم استخدام القاعدة ، وإذا كان الأمر كذلك ، ما إذا كانت هناك انحرافات عنها.

هناك حاجة إلى هذا الجدول بأكمله حتى تتمكن من معرفة قواعد الأولويات بسرعة وما إذا كان الرمز يتوافق معها أم لا. إذا كنت مهتمًا فجأة بمعرفة السبب الدقيق للانحراف ، يمكنك دائمًا الانتقال إلى خطة الامتثال والعثور على الوثائق التي تحتاجها.

لذلك قمت بكتابة الرمز بعناية بعد قواعد MISRA. لقد قمت بوضع خطة امتثال وثقت كل ما يمكن توثيقه ، وقمت بملء سيرتك الذاتية. إذا كان هذا هو الحال بالفعل ، فأنت تحصل على رمز نظيف للغاية وقابل للقراءة للغاية وموثوق به للغاية تكرهه الآن :)

أين سيعيش برنامجك الآن؟ في جهاز التصوير بالرنين المغناطيسي؟ في جهاز استشعار السرعة العادية أو في نظام التحكم في بعض الأقمار الصناعية الفضائية؟ نعم ، لقد مررت بطريق بيروقراطي خطير ، لكن هذا ليس بالأمر الكبير. عندما يتعلق الأمر بحياة بشرية حقيقية ، يجب أن تكون دائمًا دقيقًا.

إذا كنت قد تعاملت وتمكنت من الوصول إلى النهاية المنتصرة ، فأني أهنئكم بصدق: أن تكتب رمزًا آمنًا عالي الجودة. شكرا لك

مستقبل المعايير

في النهاية ، أود أن أتطرق إلى مستقبل المعايير.

الآن ميسرا تعيش وتتطور. على سبيل المثال ، "MISRA C: 2012 Third Edition (First Revision)" هي نسخة منقحة وموسعة مع إصدار قواعد جديدة تم الإعلان عنها في بداية عام 2019. وفي الوقت نفسه ، سيصدر الإصدار القادم من "MISRA C: 2012 Amendment 2 - C11 Core "، وهو معيار منقح لعام 2012 ، تم الإعلان عنه. سيتضمن هذا المستند قواعد تغطي لأول مرة إصدارات لغة C لعامي 2011 و 2018 سنة.

يستمر 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 وكيفية طبخه!

في التقليد القديم ، سأترك هنا رابطًا لمحلل الاستاتيك الثابت في PVS-Studio. إنه قادر على إيجاد ليس فقط الانحرافات عن معيار MISRA ، ولكن أيضًا مجموعة كبيرة من الأخطاء ونقاط الضعف. إذا كنت مهتمًا بتجربة PVS-Studio بنفسك ، فقم بتنزيل الإصدار التجريبي وتحقق من مشروعك.

هذا هو المكان الذي ينتهي مقالي. أتمنى لجميع القراء عيد ميلاد سعيد وعيد رأس السنة!