MISRA konsolidiert Zwei Amendments zu MISRA C:2012 münden in MISRA C:2023

Anbieter zum Thema

Hitex GmbH

Parasoft® Deutschland GmbH

In schneller Folge hat MISRA Amendment 3 und 4 zu MISRA C:2012 veröffentlicht. Kurz danach wurde mit MISRA C:2023 eine konsolidierte Version der bisherigen Amendments und technischen Korrekturen herausgegeben. Dieser Beitrag beschreibt alle Änderungen in Amendment 3 und 4 im Detail und geht auch auf frühere Änderungen ein. Daraus ergibt sich der Unterschied zwischen MISRA C:2012 und MISRA C:2023.

Standards zur Entwicklung von sicherheitskritischen Systemen wie IEC 61508 oder ISO 26262 empfehlen besonders, dass Kodierrichtlinien eingesetzt werden. Das ist besonders wichtig, wenn die „gefährliche“ Programmiersprache C verwendet wird, was in vielen Projekten nach wie vor der Fall ist. Durch die Kodierrichtlinien soll die Sprache eingeschränkt werden, um mehrdeutige Spracheigenschaften und mögliche Laufzeitfehler zu verhindern (siehe Tabelle 1 in Teil 6 von ISO 26262:2018, Methode 1b). Dies kann durch die Einhaltung der Vorgaben von MISRA [MISRA] erreicht werden. So sind die MISRA-Richtlinien zu den wichtigsten und bekanntesten Kodierrichtlinien für C geworden. ISO 26262 erwähnt MISRA sogar explizit, in der Notiz zu Tabelle 6 in Teil 6 von ISO 26262:2018.

Frühere Amendments und andere Dokumente

Die erste Ausgabe der MISRA-Richtlinien [MISRA1] erschien 1998, die zweite Ausgabe 2004 [MISRA2] und die dritte Ausgabe 2013. Das war MISRA C:2012 [MISRA3]. Seitdem wurde diese Richtlinie durch Zusatzdokumente erweitert, geändert und kommentiert (Bild 1). Wesentlich sind die Amendments (Änderungen) und die Technical Corrigenda (technischen Korrekturen), denn dadurch wird die eigentliche Richtlinie geändert. Sogenannte Addenda (Ergänzungen) vergleichen die Vorgaben in anderen Richtlinien mit den Vorgaben in MISRA C:2012; Addenda verändern MISRA C:2012 nicht. Ein Permit (Erlaubnis, Bewilligung) und die Compliance-Dokumente helfen die Konformität zu MISRA zu erreichen.

Bildergalerie

Durch Technical Corrigenda werden Fehler in der Richtlinie korrigiert oder es werden Klarstellungen vorgenommen. Durch Amendments kommen Vorgaben zur Richtlinie dazu oder es werden Vorgaben geändert.

Vorgaben können Directives (Direktiven) oder Rules (Regeln) sein. Bei Direktiven kann es schwierig sein, zu entscheiden, ob sie eingehalten sind oder nicht, insbesondere für statische Analyse-Werkzeuge. Oft werden Zusatzinformationen benötigt, beispielsweise ob der Compiler Warnungen ausgibt oder nicht. Bei Regeln können statische Analyse-Werkzeuge prinzipiell aus dem Quellcode – und Zusatzinformation, wie beispielsweise der Integer-Größe – entscheiden, ob eine Regelverletzung vorliegt oder nicht. Das wird allerdings eingeschränkt durch die Unentscheidbarkeit mancher Regeln. Die Unentscheidbarkeit ist ein Problem der Informatik und hängt nicht vom verwendeten Analyse-Werkzeug ab. Für unentscheidbare Regeln kann man „False Positives“ (Regelverletzung wird gemeldet, liegt aber in Wahrheit nicht vor) oder „False Negatives“ (Regelverletzung wird nicht gemeldet, liegt aber in Wahrheit vor) nicht vermeiden. Leider sind wichtige Fragestellungen nicht entscheidbar, beispielsweise ob ein Stack-Objekt gelesen wird, bevor es initialisiert wurde (Regel 9.1).

Das bereits ältere Amendment 1 [MISRA-AMD1] erweitert MISRA C:2012 um eine Direktive und 13 Regeln. Der Schwerpunkt von Amendment 1 ist Security (Bild 2). Amendment 2 [MISRA-AMD2] erweitert MISRA C:2012 um zwei weitere neue Regeln. Der Schwerpunkt von Amendment 2 ist die Erweiterung der Richtlinie für die Kernfunktionen des Sprachstandards C11 [C11], denn bis dahin galt MISRA nur für C90 [C90] und C99 [C99]. Natürlich kamen in beiden Amendments nicht nur neue Vorgaben hinzu, sondern es wurden auch etliche geändert.

Der Schwerpunkt der beiden kürzlich erschienenen Amendments 3 [MISRA-AMD3] und 4 [MISRA-AMD4] ist die Fortsetzung der Erweiterung von MISRA C:2012 für den Sprachstandard C11 und C18 [C18]. C18 ist aber eigentlich nur eine Korrektur von C11; deshalb ist im Folgenden mit C11 auch immer C18 mit gemeint.

Amendment 3

Amendment 3 (AMD 3) enthält eine neue Direktive und 23 neue Regeln. Drei bereits vorhandene Direktiven und neun bereits vorhandene Regeln wurden verändert. Die folgenden drei Funktionalitäten von C11 werden (mit Einschränkungen) durch AMD 3 erlaubt:
1. No-return-Funktionen,
2. die Ausrichtung von Objekten mit dem Schlüsselwort „alignas“ und
3. Typ-generische Ausdrücke.

Außerdem gibt es vertiefende Anleitungen zu drei Funktionen, die es bereits in C99 gab:
1. Typ-generische mathematische Macros,
2. Fließkommazahlen und
3. komplexe Zahlen.
Aber nicht alle neuen Vorgaben betreffen die obigen Themen, es gibt auch neue Regeln, die sogar bereits für den Sprachstandard C90 angewendet werden können, beispielsweise Regel 17.12, in der es um die unmissverständliche Verwendung von Funktionsnamen geht. Drei Direktiven und neun Regeln werden durch AMD 3 verändert.

No-return-Funktionen in AMD 3

No-return-Funktionen wurden in C11 eingeführt und sind Funktionen, die mit dem Schlüsselwort _Noreturn deklariert sind, das angibt, dass solche Funktionen nicht zu ihrem Aufrufer zurückkehren. Hiermit befassen sich drei neue Regeln (Regel 17.9 bis 17.11), die einfach zu verstehen sind, da sie einfach die „vernünftige“ Verwendung dieses Schlüsselworts fordern.

Regel 17.9 (mandatory) fordert, dass eine No-return-Funktion nicht zu der aufrufenden Funktion zurückkehren darf, denn dies wäre undefiniertes Verhalten und Schlimmes kann passieren, beispielsweise Abstürze. Leider ist diese wichtige Regel unentscheidbar.
Regel 17.10 (required) fordert, dass eine No-return-Funktion void sein muss, d.h. keinen Rückgabendatentyp haben darf.
Regel 17.11 (advisory) fordert, dass eine Funktion, die nicht zum Aufrufer zurückkehrt, als No-return-Funktion deklariert sein soll.
Da es das Schlüsselwort _Noreturn erst ab C11 gibt, gelten diese drei Regeln natürlich nur ab dieser Sprachversion.

Ausrichtung von Objekten in AMD 3

In C11 wurde das Schlüsselwort _Alignas eingeführt. Damit kann man explizit die Ausrichtung von Variablen und Typen festlegen, um schnellere Zugriffe zu ermöglichen. In C++ lautet das korrespondierende Schlüsselwort alignas, und damit man einheitliche Schlüsselworte in C und C++ verwenden kann, gibt es für C den Header <stdalign.h>, in dem alignas zu _Alignas definiert wird. Die Beispiele in AMD 3 verwenden durchgehend alignas. Drei neue Regeln 8.15 bis 8.17 befassen sich mit der Ausrichtung von Objekten. Diese Regeln verlangen, dass die Ausrichtung von Objekten „vernünftig“ erfolgt.

Regel 8.15 (required) fordert, dass alle Deklarationen und die Definition eines Objekts die gleiche Ausrichtung haben müssen. Wird diese Regel verletzt, entsteht undefiniertes Verhalten, was unbedingt vermieden werden muss. Diese Regel ist natürlich auch eingehalten, wenn für alle Deklarationen und die Definition eines Objekts keine explizite Ausrichtung angegeben ist.

Regel 8.16 (advisory) gilt der Ausrichtung mit dem Wert null, die nicht vorkommen soll. Diese Ausrichtung wird immer ignoriert, und könnte ausdrücken, dass im betreffenden Fall die Ausrichtung nicht wichtig ist. Regel 8.16 rät, dies über den Präprozessor zu bewirken.

Regel 8.17 (advisory) fordert, dass nur eine Ausrichtung für ein Objekt angegeben werden sollte. C11 erlaubt mehrere Ausrichtungen für ein Objekt anzugeben, von denen dann die strengste Ausrichtung verwendet wird.

Typ-generische Ausdrücke in AMD 3

Abhängig vom Typ einer Variablen wird aus einer Liste ein Ausdruck, der auch eine Funktion sein kann, ausgewählt. Die Liste kann auch einen default enthalten. Dies wurde in C11 durch das Schlüsselwort _Generic ermöglicht. Dadurch erhält C11 eine Art Typ-Polymorphismus. Für die Typ-generischen Ausdrücke wurden in AMD 3 acht neue Regeln eingeführt, die einen eigenen Regelabschnitt bilden: Regel 23.1 bis 23.8.
Regel 23.1 (advisory) fordert, dass eine generische Auswahl nur aus einem Macro heraus erfolgen sollte, denn wenn es direkt geschieht, ist der Typ bereits bekannt und die Auswahl überflüssig.
Regel 23.2 (required) besagt, dass wenn die generische Auswahl dennoch direkt geschieht, darf der Auswahl-Ausdruck keine Seiteneffekte enthalten, denn diese würden nicht evaluiert.
Regel 23.3 (advisory) besagt, dass die Auswahlliste mindestens eine Auswahl beinhalten sollte, die nicht default ist. Ansonsten macht die Auswahl keinen Sinn und ist wahrscheinlich so nicht gewollt.
Regel 23.4 (required) verbietet manche Typen, da der Auswahl-Ausdruck in ein lvalue umgewandelt wird. Hätte man beispielsweise einen Array-Typ oder einen Funktionstyp in der Auswahlliste, könnte dieser nie ausgewählt werden. Deshalb dürfen nicht alle Typen vorkommen.
Regel 23.5 (advisory) verlangt, dass die die generische Auswahl nicht von impliziten Pointer-Typ-Konvertierungen abhängen sollte.
Regel 23.6 (required) verlangt, dass der Auswahl-Ausdruck einen essentiellen Typ haben muss, der passend zu seinem Standard-Typ ist. Diese Regel bezieht sich auf das essentielle Typ-System der MISRA-Richtlinien. Dieses Typ-System darf nicht verletzt werden.
Regel 23.7 (advisory) sagt, dass eine generische Auswahl aus einem Macro heraus das Argument (nur) einmal evaluieren sollte. Das sollte für alle mögliche Auswahlen gelten, d.h. es soll keine Auswahl geben, die einmal evaluiert wird und eine andere, die das nicht wird.
Regel 23.8 (required) fordert, dass default in der Auswahlliste entweder als erster oder als letzter Eintrag in der Auswahlliste stehen muss. Damit kann man einfacher sehen, ob es einen solchen Eintrag gibt oder nicht. Die Regel kann natürlich nur verletzt werden, wenn es überhaupt einen default gibt.

Weitere Neuerungen durch AMD 3

Durch AMD 3 kommen außerdem neu hinzu: Direktive 4.15 und die Regeln 1.5, 6.3, 7.5, 17.12, 17.13, 18.9, 21.22, 21.23, 21.24.

Die neue Direktive 4.15 (required) fordert, dass die Auswertung von floating-point Ausdrücken nicht zur unentdeckten Erzeugung von unendlich (INF) oder not-a-number (NaN) führt. Gilt bereits für C90.
Die neue Regel 1.5 (required) verbietet die Benutzung von Sprachfunktionalitäten, die der C Sprachstandard (in Anhang F) als veraltet erklärt. Gilt bereits für C99.
Die neue Regel 6.3 (required) verbietet Bitfelder als Element einer union, denn hier ist das Verhalten durch die Implementierung definiert. Gilt bereits für C90.
Die neue Regel 7.5 (mandatory) fordert, dass das Argument eines Integer Constant Macro (wie beispielsweise UNIT32_C) eine geeignete Form hat. Das Argument muss ein Integer ohne Suffix sein und der Wert des Arguments darf nicht größer sein als durch den Macro-Namen angegeben wird. Ansonsten entsteht undefiniertes Verhalten. Gilt bereits für C99.
Die neue Regel 17.12 (advisory) verlangt, dass Funktionsnamen entweder eine nachgestellte Parameterliste (in Klammern) haben sollen oder ein vorangestelltes ‚&‘. Denn bei einem Funktionsnamen mit keinem von beiden ist unklar, ob wirklich die Adresse der Funktion gemeint ist oder ob die Parameterliste vergessen wurde. Dies soll die Wartbarkeit der Software verbessern und gilt bereits für C90.
Die neue Regel 17.13 (required) verlangt, dass ein Funktionstyp keine Typqualifizierer (wie const, volatile, restrict oder _Atomic) haben darf, denn dies erzeugt undefiniertes Verhalten. Gilt bereits für C90.
Die neue Regel 18.9 (required) steigt in die Tiefen der Programmiersprache C und soll, vereinfacht gesagt, Pointer auf Objekte mit begrenzter Lebenszeit vermeiden. Gilt bereits für C90.
Die neue Regeln 21.22 (mandatory) und 21.23 (required) betreffen die Argumente der Typ-generischen Macros aus dem Header <tgmath.h>. Sie müssen den richtigen essentiellen Typ bzw. den gleichen Standard-Typ haben. Gilt bereits für C99.
Die neue Regel 21.24 (required) verbietet die Benutzung von rand() und srand() aus der Standardbibliothek, weil es keine Garantie für die Qualität der Zufallszahlen gibt. Gilt bereits für C90.

Änderungen durch AMD 3

AMD 3 verändert drei bestehende Direktiven (Direktive 4.6, 4.9 und 4.11) und neun bestehende Regeln (Regel 1.4, 10.1, 10.3, 10.4, 10.5, 10.7, 10.8, 21.11, 21.12).

Direktive 4.6 wird für complex float erweitert. Direktive 4.9 erlaubt nun _Generic als funktions-ähnliches Macro. Direktive 4.11 wird zum Thema Präzision der trigonometrischen periodischen Funktionen im Header <math.h> erweitert. Regel 1.4 erlaubt nun die Verwendung der Schlüsselworte _Generic, _Noreturn und _Alignas, da diese in AMD 3 nun explizit behandelt werden. Der Behandlung von „complex floating“ gelten die angeführten Regeln 10.x, die auch das essentielle Typ-Modell von MISRA betreffen. Die Regel 21.11 stuft die Verwendung des Headers <tgmath.h> neu ein und die Regel 21.12 macht eine Neueinstufung für den Header <fenv.h>.

Amendment 4

Amendment 4 (AMD 4) erweitert MISRA C:2012 um drei neue Direktiven und 19 neue Regeln. Fünf Regeln wurden geändert. AMD 4 enthält auch technische Korrekturen; diese betreffen acht Regeln. AMD 4 schließt die Erweiterungen von MISRA für C11 ab und erlaubt (mit Einschränkungen) Atomic-Funktionen und Nebenläufigkeit (Threads). Außerdem gibt es vertiefende Anleitungen zu vier Problematiken, die es bereits in C90 oder C99 gab:
1. Kleine Integer-Konstanten,
2. unbenutzte Objekte,
3. verkettete Initialisierung und
4. variably-modified Arrays.
Alle drei neuen Direktiven dienen der Vermeidung von Problemen durch Nebenläufigkeit, ebenso wie fünfzehn der neuen Regeln. Es gibt vier neue Regeln ohne Bezug zur Nebenläufigkeit. Acht bereits vorhandene Regeln werden angepasst.

Drei neue Direktiven in AMD 4

Die drei neuen Direktiven sind Direktive 5.1, 5.2 und 5.3. Sie werden in einem eigenen neuen Abschnitt (Abschnitt 7.5) der Richtlinie behandelt. Alle drei Direktiven behandeln Nebenläufigkeit (concurrency). Zum Thema Nebenläufigkeit gehören Stichworte wie kritischer Datenwettlauf (data race), Ausführungsstrang (thread), Verklemmung (deadlock), atomare Objekte und gegenseitiger Ausschluss (mutex). Zum Thema Nebenläufigkeit gibt es auch neue Regeln (beispielsweise die Regel 9.7, siehe unten) und geänderte Regeln (beispielsweise Regel 11.8, siehe unten).

Alle drei neuen Direktiven zielen darauf ab, Probleme aufgrund von Nebenläufigkeit zu vermeiden. Alle drei Direktiven gelten ab dem Sprachstandard C11, da es vorher noch keine Nebenläufigkeit in C gab.

Die neue Direktive 5.1 (required) fordert, dass es keinen kritischen Datenwettlauf zwischen Ausführungssträngen (threads) geben darf. Die Ausführung eines Programms enthält einen Datenwettlauf, wenn es mindestens zwei Threads gibt, die gleichzeitig auf ein Datenobjekt zugreifen, das nicht atomar ist und bei dem nicht durch die Programmlogik ein fester Ablauf der Zugriffe vorgegeben ist, so dass die Zugriffe quasi gleichzeitig erfolgen können.
Als Beispiel für einen Datenwettlauf kann eine 32-Bit-Variable dienen, auf die nur 16-Bit-Zugriffe möglich sind. Ohne Sicherungsmaßnahmen kann es vorkommen, dass ein Thread die obersten 16-Bit liest, und bevor er die unteren 16 Bit auch lesen kann, werden diese durch einen anderen Thread geändert. Vervollständigt danach der erste Thread das Lesen der 32-Bit-Variablen durch Lesen der unteren 16 Bit, so erhält dieser Thread nicht den Wert der 32-Bit-Variablen, wie er zu Beginn der Leseoperation bestanden hat. Somit werden Daten verfälscht, und dies kann alle möglichen negativen Konsequenzen auf die Programmausführung haben.

Die neue Direktive 5.2 (required) fordert, dass es keine Verklemmung zwischen Threads geben darf. Eine Verklemmung kann durch den gegenseitigen Ausschluss des Zugriffs von zwei Threads auf gemeinsame Datenobjekte entstehen.
Eine Verklemmung liegt beispielsweise vor, wenn Thread T1 die Zugriffserlaubnis auf eine Ressource A hat und auf die Zugriffserlaubnis auf eine Ressource B wartet; diese Zugriffserlaubnis auf die Ressource B besitzt jedoch Thread T2 und T2 wartet seinerseits auf die Zugriffserlaubnis auf Ressource A. In dieser Situation kann keiner der beiden Threads fortfahren und die Anwendung „hängt“.

Die neue Direktive 5.3 (required) fordert, dass es keine dynamische Erzeugung von Threads geben darf. Alle Threads eines Programms müssen beim Start des Programms erzeugt werden, also beispielsweise direkt nach main(). Erzeugung von Threads innerhalb von Threads ist nicht erlaubt. Dadurch ist während des eigentlichen Betriebs des Programms zu jedem Zeitpunkt bekannt, wie viele und welche Threads es gibt. Das erleichtert das Verständnis des Programms und das ist der Hintergrund dieser Forderung nach statischen Threads.

(ID:49861959)