Was ist MISRA und wie kocht man es?

Vielleicht hat jeder Entwickler von Programmen für Mikrocontroller mindestens einmal von speziellen Codierungsstandards gehört, die dazu beitragen sollen, die Sicherheit und Portabilität Ihres Codes zu erhöhen. Ein solcher Standard ist MISRA. In diesem Artikel werden wir detaillierter untersuchen, was dieser Standard ist, was seine Philosophie ist und wie er in Ihren Projekten verwendet wird.

Viele unserer Leser haben gehört, dass PVS-Studio die Klassifizierung ihrer Alarme nach dem MISRA-Standard unterstützt. Derzeit deckt PVS-Studio mehr als 100 MISRA C: 2012- und MISRA C ++: 2008-Regeln ab.

Dieser Artikel zielt darauf ab, drei Fliegen mit einer Klappe zu schlagen:

1. Sagen Sie, was MISRA für diejenigen ist, die mit diesem Standard nicht vertraut sind.
2. Erinnern Sie die eingebettete Welt an das, wozu wir fähig sind;
3. Unterstützung bei der Vertiefung des Geschäftsverlaufs für neue Mitarbeiter, die auch unseren MISRA-Analysator weiterentwickeln werden;

Ich hoffe ich kann es interessant machen. Also fangen wir an!

MISRA Geschichte

Die Geschichte von MISRA begann vor langer Zeit. In den frühen 90er Jahren stellte das britische Regierungsprogramm unter dem indikativen Namen "Safe IT" Mittel für verschiedene Projekte zur Verfügung, die sich auf die eine oder andere Weise auf die Sicherheit elektronischer Systeme bezogen. Das MISRA-Projekt (Motor Industry Software Reliability Association) wurde gegründet, um einen Leitfaden für die Entwicklung von Software für Mikrocontroller in Landfahrzeugen zu erstellen - in Autos im Allgemeinen.

Das vom Staat finanzierte MISRA-Team machte sich an die Arbeit und veröffentlichte im November 1994 seinen ersten Leitfaden: " Entwicklungsrichtlinien für fahrzeugbasierte Software ". Dieser Leitfaden ist noch nicht an eine bestimmte Sprache gebunden, aber ich muss zugeben: Die Arbeit war beeindruckend und betraf wahrscheinlich alle denkbaren Aspekte der Entwicklung eingebetteter Software. Übrigens haben die Entwickler dieses Handbuchs kürzlich das 25-jährige Jubiläum eines für sie so wichtigen Termins gefeiert .

Als die Finanzierung durch den Staat endete, beschlossen die Mitglieder der MISRA, weiterhin informell zusammenzuarbeiten - dies dauert bis heute an. Tatsächlich ist MISRA (als Organisation) eine Gemeinschaft von Interessenvertretern aus verschiedenen Branchen des Automobil- und Flugzeugbaus. Nun sind diese Parteien:

• Bentley-Kraftfahrzeuge
• Ford Motor Company
• Jaguar Land Rover
• Delphi-Dieselsysteme
• HORIBA MIRA
• Protean elektrisch
• Ingenieurdienstleistungen von Visteon
• Die Universität von Leeds
• Ricardo uk
• ZF TRW

Sehr starke Marktteilnehmer, nicht wahr? Es ist nicht überraschend, dass ihr erster sprachbezogener Standard, MISRA C, unter unternehmenskritischen Embedded-Entwicklern breite Akzeptanz gefunden hat. MISRA C ++ erschien etwas später. Allmählich wurden die Versionen der Standards aktualisiert und verfeinert, um die neuen Funktionen der Sprachen abzudecken. Zum Zeitpunkt dieses Schreibens sind die aktuellen Versionen MISRA C: 2012 und MISRA C ++: 2008.

Philosophie und Regelbeispiele

Das Besondere an MISRA ist die unglaubliche Liebe zum Detail und die äußerste Sorgfalt bei der Gewährleistung der Sicherheit. Die Autoren haben nicht nur alle „Löcher“ in C und C ++, die ihnen in den Sinn kamen (wie zum Beispiel die Autoren von CERT), an einer Stelle gesammelt, sondern die internationalen Standards dieser Sprachen sorgfältig ausgearbeitet und alle denkbaren und undenkbaren Fehler aufgeschrieben. Und dann haben sie die Regeln zur Lesbarkeit von Code von oben übernommen und hinzugefügt - dies soll es schwieriger machen, einen neuen Fehler in bereits sauberen Code einzufügen.

Um das Ausmaß des Ernstes zu verstehen, sollten Sie einige Regeln berücksichtigen, die der Norm entnommen sind.

Einerseits gibt es viele gute, geeignete Regeln, die immer befolgt werden sollten, unabhängig davon, wofür Ihr Projekt bestimmt ist. Zum größten Teil sollen sie undefiniertes / nicht angegebenes / implementierungsabhängiges Verhalten beseitigen. Zum Beispiel:

• Verwenden Sie nicht den Wert einer nicht initialisierten Variablen
• Verwenden Sie den FILE-Zeiger nicht, nachdem Sie den Stream geschlossen haben
• Alle nicht leeren Funktionen müssen einen Wert zurückgeben.
• Der Schleifenzähler darf keinen Gleitkomma-Typ haben
• … usw.

Auf der anderen Seite gibt es Regeln, deren Nutzen an der Oberfläche liegt, die aber (aus Sicht gewöhnlicher Projekte) nicht so sündig sind, dass sie brechen:

• Verwenden Sie nicht goto und longjmp
• Jeder Switch sollte mit der Standardeinstellung enden
• Schreiben Sie keinen nicht erreichbaren Code
• Verwenden Sie keine variablen Funktionen
• Verwenden Sie keine Adressarithmetik (außer [] und ++ )
• ...

Solche Regeln sind auch nicht schlecht und bieten in Kombination mit den vorherigen bereits eine spürbare Erhöhung der Sicherheit. Aber reicht dies für hochverantwortliche eingebettete Systeme aus? Sie werden nicht nur in der Automobilindustrie, sondern auch im Flugzeugbau, in der Luft- und Raumfahrt, im Militär und in der Medizintechnik eingesetzt.

Wir möchten nicht, dass einige Patienten aufgrund eines Softwarefehlers mit einem Röntgengerät mit einer Dosis von 20.000 Rad bestrahlt werden. Daher reichen die üblichen „alltäglichen“ Regeln nicht mehr aus. Auf dem Spiel stehen Menschenleben und riesige Geldsummen, und Sorgfalt muss einbezogen werden. Hier gehen die restlichen MISRA-Regeln auf die Bühne:

• Das Suffix 'L' im Literal sollte immer in Großbuchstaben geschrieben werden (das kleine 'l' kann mit der Einheit verwechselt werden)
• Verwenden Sie nicht den Komma-Operator (dies erhöht die Wahrscheinlichkeit, einen Fehler zu machen)
• Keine Rekursion verwenden (ein kleiner Mikrocontroller-Stack kann leicht überlaufen)
• Die Körper der Anweisungen if , else for , while , do , switch müssen in geschweifte Klammern eingeschlossen werden (Sie können möglicherweise einen Fehler machen, wenn der Code nicht richtig ausgerichtet ist ).
• Verwenden Sie keinen dynamischen Speicher (da insbesondere bei Mikrocontrollern die Möglichkeit besteht, dass die Zuordnung vom Heap nicht erfolgreich durchgeführt wird).
• ... und viele, viele solcher Regeln.

Menschen, die auf MISRA stoßen, sind oft der Meinung, dass die Philosophie des Standards darin besteht, "dies zu verbieten und dies zu verbieten". In der Tat ist dies so, aber nur zum Teil.

Ja, der Standard hat viele ähnliche Regeln, aber sein Zweck ist es nicht, alles Mögliche zu verbieten, sondern alle Möglichkeiten aufzulisten, um die Sicherheit des Codes irgendwie zu verletzen. Bei den meisten Regeln entscheiden Sie, ob Sie sie befolgen möchten oder nicht. Ich werde dies genauer erklären.

In MISRA C lassen sich Regeln in drei Hauptkategorien einteilen: Obligatorisch, Erforderlich und Beratung. Obligatorisch - das sind Regeln, die unter keinem Vorwand verletzt werden dürfen. Beispielsweise enthält dieser Abschnitt die Regel "Verwenden Sie nicht den Wert einer nicht initialisierten Variablen". Die vorgeschriebenen Regeln sind weniger streng: Sie sehen die Möglichkeit der Ablehnung vor, jedoch nur, wenn diese Abweichungen sorgfältig dokumentiert und schriftlich begründet werden. Die übrigen Regeln sind in der Kategorie "Beratung" enthalten. Hierbei handelt es sich um Regeln, die nicht befolgt werden müssen.

MISRA C ++ ist etwas anders: Dort fehlt die obligatorische Kategorie, und die meisten Regeln gehören zur Kategorie Erforderlich. Daher haben Sie in der Tat das Recht, gegen eine Regel zu verstoßen - denken Sie nur daran, die Abweichungen zu dokumentieren. Es gibt auch eine Kategorie Dokument - dies sind verbindliche Regeln (Abweichungen sind nicht zulässig), die mit gängigen Vorgehensweisen wie „Jede Verwendung von Assembler sollte dokumentiert werden“ oder „Die Plug-in-Bibliothek muss MISRA C ++ entsprechen“ verknüpft sind.

Was gibt es sonst noch?

Tatsächlich besteht MISRA nicht nur aus einem Regelwerk. In der Tat ist dies ein Handbuch zum Schreiben von sicherem Code für Mikrocontroller, und daher steckt es voller allerlei Nützlichkeiten. Schauen wir sie uns genauer an.

Erstens enthält der Standard eine ziemlich gründliche Beschreibung des Hintergrunds: Um zu verstehen, was der Standard geschaffen hat, warum C oder C ++ gewählt wurde, welche Vor- und Nachteile diese Sprachen haben.

Wir sind uns der Tugenden dieser Sprachen bewusst. Ja, und über die Mängel im Allgemeinen auch :) Was sind die hohe Komplexität, die unvollständige Spezifikation des Standards und die Syntax, die es sehr leicht machen, Fehler zu machen und dann lange nach Fehlern zu suchen? Sie könnten beispielsweise versehentlich Folgendes schreiben:

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

Dennoch besteht die Möglichkeit, dass eine Person kein zusätzliches Semikolon bemerkt, oder? Sie können auch so schreiben:

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

Es ist gut, dass der erste und der zweite Fall leicht von den MISRA-Regeln erfasst werden (der erste ist MISRA C: 13.4 / MISRA C ++: 6.2.1, der zweite ist MISRA C: 13.4 / MISRA C ++: 6.2.1).

Der Standard beschreibt nicht nur die Probleme, sondern enthält auch eine Vielzahl von Tipps, die Sie vor dem Start benötigen: Informationen zum Einrichten des MISRA-Entwicklungsprozesses, zur Verwendung statischer Analysegeräte zur Überprüfung des Codes auf Konformität, zu welchen Dokumenten Sie welche Dokumente aufbewahren müssen und wie füllen und so weiter und so fort.

Außerdem gibt es am Ende Anwendungen, die Folgendes enthalten: eine kurze Liste und eine Übersichtstabelle mit Regeln, eine kleine Liste mit C / C ++ - Schwachstellen, ein Beispiel für die Dokumentation von Abweichungen von der Regel sowie mehrere Checklisten, mit denen Sie sich nicht in der gesamten Bürokratie verlaufen können.

Wie Sie sehen, ist MISRA nicht nur ein Regelwerk, sondern fast eine gesamte Infrastruktur zum Schreiben von sicherem Code für eingebettete Systeme.

Verwenden Sie in Ihren Projekten

Stellen Sie sich eine Situation vor: Sie werden ein Programm für ein sehr notwendiges und verantwortungsbewusstes Embedded-System schreiben. Oder Sie haben bereits ein Programm, müssen es jedoch an MISRA „übertragen“. Wie können Sie Ihren Code auf Übereinstimmung mit dem Standard überprüfen? Müssen Sie es wirklich manuell machen?

Die manuelle Codeüberprüfung ist keine einfache und möglicherweise unmögliche Aufgabe. Jeder Rezensent müsste nicht nur jede Codezeile sorgfältig durchsehen, sondern auch den Standard auswendig kennen. Horror!

MISRA-Entwicklern wird daher empfohlen, statische Analysen zum Testen des Codes zu verwenden. Tatsächlich ist die statische Analyse ein automatisierter Codeüberprüfungsprozess. Sie führen den Analyzer einfach mit Ihrem Programm aus und in wenigen Minuten erhalten Sie einen Bericht über mögliche Verstöße gegen den Standard. Was brauchst du, richtig? Sie müssen nur das Protokoll anzeigen und die Antwort korrigieren.

Nächste Frage: Ab wann setzen Sie MISRA ein? Die Antwort ist einfach: Je früher, desto besser. Idealerweise, bevor Sie überhaupt mit dem Schreiben von Code beginnen, da MISRA davon ausgeht, dass Sie den Standard während der gesamten Lebensdauer Ihres Codes einhalten.

Natürlich ist es nicht immer möglich, MISRA von Anfang an zu schreiben. Beispielsweise kommt es häufig vor, dass ein Projekt bereits teilweise oder vollständig umgesetzt wurde, der Kunde jedoch wünschte, dass das Projekt dem Standard entspricht. In diesem Fall müssen Sie den vorhandenen Code gründlich überarbeiten.

Hier taucht die Falle auf. Ich würde sogar sagen, dass ein Unterwasser-Felsbrocken auftaucht. Was passiert, wenn Sie einen statischen Analysator nehmen und das „normale“ Projekt auf Übereinstimmung mit dem MISRA-Standard prüfen? Spoiler: Sie können Angst bekommen.

Das abgebildete Beispiel ist natürlich übertrieben. Hier sehen Sie das Ergebnis der Überprüfung eines ausreichend großen Projekts, an das bei der Arbeit an Mikrocontrollern eigentlich nie gedacht wurde. Wenn Sie jedoch einen vorhandenen Code überprüfen, sehen Sie möglicherweise einen, zwei, fünf oder sogar zehntausend Analysevorgänge. Und in diesem ganzen Haufen gehen neue Operationen verloren, die für den gerade geschriebenen oder geänderten Code ausgegeben wurden.

Was ist dagegen zu tun? Ist es wirklich notwendig, alle Dinge beiseite zu legen und sich zu setzen, um alle alten Positiven zu beheben?

Wir wissen, dass beim erstmaligen Überprüfen eines Projekts häufig positive Ergebnisse auftreten und haben eine Lösung entwickelt, mit der Sie den Nutzen des Analysegeräts sofort erzielen können, ohne die Arbeit zu unterbrechen. Diese Lösung wird als "Unterdrückungsbasis" bezeichnet.

Suppress-Bases ist der PVS-Studio-Mechanismus, mit dem Analysatormeldungen massiv unterdrückt werden können. Wenn Sie ein Projekt zum ersten Mal überprüfen und dort mehrere tausend positive Ergebnisse feststellen, fügen Sie diese einfach der Unterdrückungsdatenbank hinzu. Wenn Sie den Analyzer das nächste Mal ausführen, erhalten Sie keine Warnungen.

Auf diese Weise können Sie den Code wie gewohnt weiter schreiben und ändern. Gleichzeitig werden nur Warnungen zu den Fehlern angezeigt, die gerade in das Projekt eingefügt wurden. Gleichzeitig können Sie hier und jetzt den größtmöglichen Nutzen aus dem Analysegerät ziehen, ohne von alten Fehlern abgelenkt zu werden. Ein paar Klicks - und der Analyzer ist implementiert! Eine ausführliche Anleitung dazu finden Sie hier .

Vielleicht fragen Sie sich: „Warten Sie, was tun mit versteckten Antworten?“ Die Antwort ist ganz einfach: Vergessen Sie sie nicht und korrigieren Sie sie leise. Sie können beispielsweise die Unterdrückungsbasis im Versionskontrollsystem verlegen und nur die Festschreibungen zulassen, die die Anzahl der Vorgänge nicht erhöhen. So wird Ihr "Unterwasser-Boulder" früher oder später nach und nach abgelassen und es gibt keine Spur davon.

Okay, der Analyzer ist implementiert und jetzt können wir weitermachen. Was ist als nächstes zu tun? Klares Geschäft - um mit dem Code zu arbeiten. Aber was ist erforderlich, um die Konformität mit der Norm zu erklären? Wie können Sie nachweisen, dass Ihr Projekt MISRA-konform ist?

Tatsache ist, dass es kein spezielles „Zertifikat“ gibt, dass Ihr Code MISRA entspricht. Wie der Standard selbst vorschreibt, sollte die Verfolgung des Compliance-Codes von zwei Parteien durchgeführt werden: dem Software-Kunden und dem Software-Anbieter. Der Lieferant entwickelt standardkonforme Software und füllt die erforderlichen Unterlagen aus. Der Kunde seinerseits hat dafür Sorge zu tragen, dass die Angaben aus diesen Unterlagen zutreffend sind.

Wenn Sie selbst Kunde und Entwickler Ihrer eigenen Software sind, liegt die Verantwortung für die Einhaltung des Standards nur bei Ihnen :)

Um die Konformität Ihres Projekts nachzuweisen, benötigen Sie im Allgemeinen Nachweise. Die Liste der Dokumente, die Projektentwickler vorbereiten sollten, kann variieren, MISRA bietet jedoch einige als Referenz an. Lassen Sie uns diese Menge genauer betrachten.

Um die Konformität mit dem Standard zu behaupten, benötigen Sie ein paar Dinge:

• Eigentlich ein Projekt, dessen Code den obligatorischen und erforderlichen Regeln entspricht
• Führungsdurchsetzungsplan
• Dokumentation aller Compiler- und Static-Analyzer-Warnungen
• Dokumentation aller Abweichungen von den geforderten Regeln
• Richtlinien-Compliance-Zusammenfassung

Der erste ist ein Compliance-Plan. Dies ist Ihr wichtigster Tisch, und er wird den Prüfer zu allen anderen Dokumenten schicken. In der ersten Spalte finden Sie eine Liste der MISRA-Regeln. Im Übrigen wird vermerkt, ob Abweichungen von diesen Regeln festgestellt wurden. Diese Tabelle sieht ungefähr so ​​aus:

Der Standard empfiehlt, Ihr Projekt mit mehreren Compilern zu erstellen und zwei oder mehr statische Analysatoren zu verwenden, um den Code auf Konformität zu überprüfen. Wenn der Compiler oder Analysator eine mit der Regel verknüpfte Warnung generiert, sollten Sie dies in der Tabelle und im Dokument vermerken: Warum kann die Operation nicht beseitigt werden, ob sie falsch ist usw.

Wenn eine der Regeln nicht mit einem statischen Analysegerät überprüft werden kann, müssen Sie die Codeüberprüfung durchführen. Dieses Verfahren sollte ebenfalls dokumentiert werden. Anschließend sollte ein Link zu dieser Dokumentation zum Compliance-Plan hinzugefügt werden.

Wenn sich der Compiler oder der statische Analysator als richtig herausstellt oder wenn während des Codeüberprüfungsprozesses tatsächliche Codeverletzungen festgestellt wurden, müssen Sie diese entweder korrigieren oder dokumentieren. Wieder durch Anhängen eines Links zur Dokumentation in der Tabelle.

Ein Compliance-Plan ist somit ein Dokument, anhand dessen Sie die Dokumentation für jede in Ihrem Code festgestellte Abweichung finden können.

Nun ein wenig zur Dokumentation von Regelabweichungen. Wie ich bereits erwähnt habe, ist eine solche Dokumentation nur für die erforderlichen Regeln erforderlich, da Sie nicht gegen Regeln der obligatorischen Ebene verstoßen können und die Beratungsregeln nicht ohne Dokumentation befolgt werden können.

Wenn Sie sich entscheiden, von der Regel abzuweichen, sollte die Dokumentation Folgendes enthalten:

• Nummer der gebrochenen Regel
• Genaue Abweichungsstelle
• Die Gültigkeit der Abweichung
• Der Nachweis, dass Abweichungen die Sicherheit nicht beeinträchtigen
• Mögliche Auswirkungen auf den Benutzer

Wie Sie sehen, lässt dieser Dokumentationsansatz Sie ernsthaft darüber nachdenken, ob sich der Verstoß lohnt. Dies geschah speziell, um die Required-Regeln zu verletzen war nicht gut :)

Nun zur Zusammenfassung der Einhaltung der Regeln. Dieses Papier ist vielleicht am einfachsten auszufüllen:

Die mittlere Spalte wird gefüllt, bevor Sie mit der Arbeit mit dem Code beginnen, und die Spalte ganz rechts befindet sich, nachdem Ihr Projekt fertig ist.

Es ist durchaus sinnvoll, eine Frage zu stellen: Warum müssen Sie Kategorien von Regeln angeben, wenn diese bereits in der Norm selbst festgelegt sind? Tatsache ist, dass der Standard die "Erhöhung" der Regel in einer strengeren Kategorie erlaubt. Beispielsweise kann ein Kunde Sie auffordern, eine Beratungsregel in eine Kategorie zu verschieben. Eine solche „Erhöhung“ muss vorgenommen werden, bevor mit dem Code gearbeitet wird, und eine Zusammenfassung der Einhaltung der Regeln ermöglicht es, dies klar zu vermerken.

Bei der letzten Spalte ist alles einfach: Es reicht aus, nur zu notieren, ob die Regel verwendet wird, und wenn ja, gibt es Abweichungen davon.

Diese ganze Tabelle wird benötigt, damit Sie schnell sehen können, welche Prioritäten die Regeln haben und ob der Code mit ihnen übereinstimmt. Wenn Sie plötzlich Interesse daran haben, den genauen Grund für die Ablehnung zu erfahren, können Sie jederzeit auf den Compliance-Plan verweisen und die benötigten Unterlagen finden.

Sie haben den Code also sorgfältig gemäß den MISRA-Regeln geschrieben. Sie haben einen Compliance-Plan erstellt, alles dokumentiert und eine Compliance-Zusammenfassung ausgefüllt. Wenn dies zutrifft, haben Sie sehr sauberen, sehr lesbaren und sehr zuverlässigen Code erhalten, den Sie jetzt hassen :)

Wo wird dein Programm jetzt leben? In einem MRT-Gerät? In einem gewöhnlichen Geschwindigkeitssensor oder im Autopilotsystem eines Weltraumsatelliten? Ja, Sie sind einen ernsthaften bürokratischen Weg gegangen, aber das sind Kleinigkeiten. Wie kann man nicht akribisch sein, wenn es um echte Menschenleben geht?

Wenn Sie es geschafft haben und es geschafft haben, ein siegreiches Ende zu erreichen, dann gratuliere ich Ihnen ganz herzlich: Sie schreiben hochwertigen, sicheren Code. Vielen Dank!

Die Zukunft der Standards

Abschließend möchte ich ein wenig über die Zukunft der Normen sprechen.

MISRA lebt und entwickelt sich derzeit. Beispielsweise wurde Anfang 2019 „Die dritte Ausgabe von MISRA C: 2012 (Erste Überarbeitung)“ angekündigt - eine aktualisierte und durch neue Regeln 2012 ergänzte Norm. Gleichzeitig kündigten sie die bevorstehende Veröffentlichung von MISRA C: 2012, Änderung 2 - C11 Core, dem 2012er Standard, an, in dem Regeln hinzugefügt werden, die zum ersten Mal die Versionen der C-Sprache für 2011 und 2018 abdecken.

Steht nicht still und MISRA C ++. Wie Sie wissen, stammt der neueste MISRA C ++ - Standard aus dem Jahr 2008, sodass die älteste Version der Sprache, die er abdeckt, C ++ 03 ist. Aus diesem Grund gibt es einen anderen Standard, der MISRA ähnelt und AUTOSAR C ++ heißt. Es war ursprünglich als Fortsetzung von MISRA C ++ konzipiert und sollte spätere Sprachversionen abdecken. Im Gegensatz zu seinem Mastermind wird AUTOSAR C ++ zweimal im Jahr aktualisiert und unterstützt derzeit C ++ 14. Ein weiteres Upgrade auf C ++ 17, dann C ++ 20 usw. ist geplant.

Was habe ich mit einem anderen Standard angefangen? Tatsache ist, dass beide Organisationen vor etwas weniger als einem Jahr die Vereinheitlichung ihrer Standards in einem angekündigt haben. Jetzt werden MISRA C ++ und AUTOSAR C ++ zu einem einzigen Standard, und jetzt werden sie gemeinsam entwickelt. Ich denke, dies sind großartige Neuigkeiten für Entwickler, die unter C ++ - Mikrocontrollern schreiben, und nicht weniger großartige Neuigkeiten für Entwickler von statischen Analysatoren. Vor uns liegt noch viel Lieblingsarbeit! :)

Fazit

Heute haben wir viel über MISRA gelernt: Wir haben die Geschichte seines Auftretens gelesen, Beispiele für Regeln und die Philosophie des Standards studiert, alles in Betracht gezogen, was Sie für die Verwendung von MISRA in Ihren Projekten benötigen, und sogar ein wenig in die Zukunft geschaut. Ich hoffe, Sie verstehen jetzt besser, was MISRA ist und wie man es kocht!

Nach alter Tradition werde ich hier einen Link zu unserem PVS-Studio Static Analyzer hinterlassen. Es kann nicht nur Abweichungen vom MISRA-Standard feststellen, sondern auch eine Vielzahl von Fehlern und Schwachstellen. Wenn Sie PVS-Studio selbst ausprobieren möchten, laden Sie die Demoversion herunter und überprüfen Sie Ihr Projekt.

Damit ist mein Artikel abgeschlossen. Ich wünsche allen Lesern ein frohes neues Jahr und ein frohes neues Jahr!

Sitelinks

1. Georgy Gribkov - " Sicherheit mit maximaler Geschwindigkeit - wie man zuverlässigen C / C ++ - Code für eingebettete Systeme schreibt ."
2. PVS-Studio ist ein statischer Code-Analysator .
3. PVS-Studio & KEIL 5 Zusammenarbeit .

Wenn Sie diesen Artikel mit einem englischsprachigen Publikum teilen möchten, verwenden Sie bitte den Link zur Übersetzung: George Gribkov. Was ist MISRA und wie kocht man es?