MISRA C ist ein Codierstandard von MISRA, ursprünglich der Motor Industry Software Reliability Association, der eine sichere Teilmenge von C für kritische Systeme definiert; die erste Ausgabe erschien 1998 für Software in Fahrzeugen. Er streicht oder beschränkt Sprachteile mit undefiniertem oder unspezifiziertem Verhalten und ordnet jede Richtlinie als Mandatory, Required oder Advisory ein. Mandatory-Richtlinien erlauben keine Ausnahme, Required-Richtlinien nur eine formale, dokumentierte Abweichung, und Advisory-Richtlinien darf ein Projekt lockern; Compliance heißt, dass jede Verletzung behoben oder begründet ist, nicht null Warnungen.

MISRA C

Details
Vollständiger Name

MISRA C — Guidelines for the use of the C language in critical systems, herausgegeben von MISRA, ursprünglich der Motor Industry Software Reliability Association. Erste Ausgabe 1998, damals für Software in Fahrzeugen; der obige Titel gilt seit MISRA C:2004, danach folgten MISRA C:2012, die konsolidierte Ausgabe MISRA C:2023 und die inkrementelle Aktualisierung MISRA C:2025 (misra.org.uk).

Auch bekannt als

die MISRA-Richtlinien, MISRA-Regeln; Ausgaben nach Jahr, etwa MISRA C:2012

Kernkonzepte:

Eine sichere Teilmenge von C

MISRA C fügt der Sprache nichts hinzu. Es streicht oder beschränkt die Teile, deren Verhalten undefiniert oder unspezifiziert ist oder die sich in der Praxis als fehleranfällig erwiesen haben. Implementierungsabhängiges Verhalten ist nicht pauschal verboten; wo das Programm davon abhängt, muss es dokumentiert sein. Übrig bleibt ein C, über das ein Reviewer und ein statischer Analysator verlässlich urteilen können.

Mandatory, Required, Advisory

Jede Richtlinie trägt eine Kategorie. Mandatory-Richtlinien lassen keine Ausnahme zu. Required-Richtlinien dürfen nur über eine formale, dokumentierte Abweichung verletzt werden. Advisory-Richtlinien sind Empfehlungen, die ein Projekt lockern darf.

Directives und Rules

Rules sind so genau formuliert, dass man sie am Quellcode prüfen kann. Directives betreffen den Prozess und die begleitende Dokumentation und lassen sich am Code allein nicht vollständig prüfen. Ein Werkzeugbericht deckt die Rules ab — vollständig nur die entscheidbaren — und die Directives bestenfalls teilweise.

Abweichung statt Schweigen

Eine Required-Richtlinie zu verletzen ist erlaubt, aber nur mit einer schriftlichen Abweichung (Deviation), die Richtlinie, Grund, Geltungsbereich und Freigabe nennt. Compliance heißt „jede Verletzung ist behoben oder begründet“, nicht „null Warnungen“.

Das Essential Type Model

MISRA C argumentiert über den Typ, den ein Wert wirklich hat — Boolean, Zeichen, vorzeichenbehaftet, vorzeichenlos, Enum, Gleitkomma — statt über Cs Integer-Promotions. Implizite Umwandlungen zwischen diesen Kategorien, vor allem einengende und solche, die Vorzeichen mischen, soll das Modell verhindern.

Typische Themen

keine dynamische Speicherverwaltung, keine Rekursion, eingeschränkte Zeigerarithmetik, ein default in jedem switch, geschweifte Klammern um jeden Rumpf, jeder Rückgabewert geprüft oder ausdrücklich verworfen, kein unerreichbarer oder ungenutzter Code, eingeschränkter Präprozessor und eingeschränkte Standardbibliothek.

Die Regeltexte gehören MISRA

Die Texte der Richtlinien sind urheberrechtlich geschützt und werden von MISRA verkauft. Themen und Kategorien darf man frei nennen; für eine einzelne Regelnummer und ihren Wortlaut sind das lizenzierte Dokument und ein qualifizierter Checker die Referenz — nicht das Gedächtnis eines Modells.

Wann zu verwenden:

  • Embedded C für Automotive, Bahn, Medizintechnik, Luftfahrt oder Industriesteuerung, wo eine Norm zur funktionalen Sicherheit wie iec-61508-sil-levels einen Codierstandard erwartet

  • C-Code so reviewen oder umschreiben, dass der MISRA-Bericht eines statischen Analysators zur Review-Checkliste wird

  • Die Compliance-Politik eines Projekts festlegen: welche Ausgabe, welche Advisory-Richtlinien gelockert werden, wer Abweichungen freigibt

  • Ein Modell steuern: „mach das MISRA-C-konform und liste jede Abweichung mit Begründung auf“ verlangt die Teilmenge und die Dokumentation, nicht nur sichereren Code

Häufige Missverständnisse:

  • ❌ „MISRA-Compliance heißt null Warnungen“ — sie heißt, dass jede Verletzung behoben oder durch eine freigegebene Abweichung gedeckt ist

  • ❌ „MISRA ist nur etwas für Autos“ — der Name ist seiner Herkunft entwachsen; die Richtlinien gelten überall, wo C in kritischen Systemen läuft

  • ❌ „Regelnummern aus einem Modell kann man übernehmen“ — in der Messung vom 2026-10-09 nannte ein Modell eine „Rule 34.1“, die es in MISRA C nicht gibt; Nummern gegen das lizenzierte Dokument oder einen Checker prüfen

  • ❌ „MISRA C macht C sicher“ — es beseitigt bekannte Gefahrenquellen; es beweist nicht, dass das Programm korrekt ist

  • ✓ „Die Ausgabe verwenden, auf die sich das Projekt festgelegt hat, mit einem Werkzeug prüfen und jede Abweichung aufschreiben“

Kritik:

Aktueller Stand:

  • Ein Modell hat vermutlich MISRA C:2012 im Kopf. MISRA nennt MISRA C:2012 als am 18. März 2013 erschienen, MISRA C:2023 als im April 2023 erschienen, um die Arbeit der Zwischenjahre zu konsolidieren und C11 und C18 zu unterstützen, und MISRA C:2025 als im März 2025 erschienene inkrementelle Aktualisierung. MISRA, „MISRA C“. Die Ausgabe nennen, die das Projekt verwendet; die Nummern der Richtlinien unterscheiden sich zwischen den Ausgaben.