Programmierrichtlinien MISRA C++:2023, TC1:2026: Was Teams im Bereich Embedded C++ wissen müssen

Von Ricardo Camacho* 10 min Lesedauer

Anbieter zum Thema

MISRA hat die erste technische Korrektur für MISRA C++:2023 veröffentlicht. TC1:2026 präzisiert die Auslegung der Regeln, fügt neue Ausnahmen hinzu und passt den Analyseumfang bei mehreren Richtlinien an.

MISRA hat im September 2026 als Addendum die erste Technische Korrektur für MISRA C++:2023 veröffentlicht. Wie aus dem Vorwort der Arbeitsgruppe hervorgeht, enthält TC1:2026 keine neuen Richtlinien, sondern entspricht in vollem Umfang MISRA C++:2023; sie beseitigt jedoch Unklarheiten und Probleme, die die Arbeitsgruppe, Tool-Anbieter und Anwender seit der ursprünglichen Veröffentlichung im Jahr 2023 festgestellt haben.(Bild:  Parasoft/TippaPatt/Shutterstock)
MISRA hat im September 2026 als Addendum die erste Technische Korrektur für MISRA C++:2023 veröffentlicht. Wie aus dem Vorwort der Arbeitsgruppe hervorgeht, enthält TC1:2026 keine neuen Richtlinien, sondern entspricht in vollem Umfang MISRA C++:2023; sie beseitigt jedoch Unklarheiten und Probleme, die die Arbeitsgruppe, Tool-Anbieter und Anwender seit der ursprünglichen Veröffentlichung im Jahr 2023 festgestellt haben.
(Bild: Parasoft/TippaPatt/Shutterstock)

Programmierstandards entwickeln sich zwangsläufig weiter, wenn sie in der Praxis auf echte Software angewendet werden. Es treten Unklarheiten auf, Beispiele decken Grenzfälle auf und legitime Programmiermuster bedürfen mitunter einer zusätzlichen Klarstellung.

Eine technische Korrektur bietet die Möglichkeit, diese Probleme anzugehen, ohne den zugrunde liegenden Standard zu ersetzen. TC1 tut genau dies für MISRA C++:2023 und liefert die redaktionellen Anweisungen zur Aktualisierung der Richtlinien auf MISRA C++:2023 (TC1:2026). Einige Änderungen sind relativ geringfügig, andere haben jedoch direkte Auswirkungen auf die statische Analyse. So kann ein Konstrukt, das zuvor als Verstoß behandelt wurde, nun unter eine definierte Ausnahme fallen. Andere Änderungen präzisieren wiederum, welche Informationen ein Analysator über das Programmverhalten verstehen muss, um die Konformität korrekt zu bestimmen. Es gibt auch Fälle, in denen sich der erforderliche Analyseumfang selbst geändert hat. Zusammenfassend unterstreichen diese Aktualisierungen einen wichtigen Punkt: Eine sinnvolle MISRA-Unterstützung besteht nicht einfach darin, für jede Regel einen Checker bereitzustellen. Der Checker muss auch die aktuelle Absicht und Semantik der Richtlinie umsetzen.

Wichtige Erkenntnisse:

  • TC1 ändert die Auslegung, nicht die Regel-Nummern. Ausnahmen, Klarstellungen und Änderungen des Anwendungsbereichs bedeuten, dass Analysetools ihre Logik aktualisieren müssen, da sonst die Gefahr besteht, dass konformer Code fälschlicherweise als fehlerhaft markiert wird und tatsächliche Verstöße übersehen werden.
  • Moderne C++-Muster werden besser berücksichtigt. Aktualisierungen wie die CRTP-Ausnahme und die verfeinerte „moved-from“-Semantik zeigen, dass TC1 sichere, gängige Muster zulässt.
  • Der Analyseumfang verschiebt sich in beide Richtungen. Einige Regeln erfordern nun systemweite Sichtbarkeit. Andere beschränken sich auf eine einzelne Datei. Das bedeutet: Die Tools benötigen eine regel-spezifische Analysetiefe und keinen einheitlichen Ansatz. Parasoft C/C++test unterstützt diese Aktualisierungen vollständig.

Wie sich MISRA C++:2023 TC1 im tatsächlichen Code darstellt

Mehrere TC1-Aktualisierungen befassen sich mit Programmierkonstrukten, denen Entwickler:innen im modernen C++-Code regelmäßig begegnen. Eines der einfachsten Beispiele findet sich in Regel 0.0.2, in der TC1 eine Ausnahme einführt, die einen Steuerausdruck zulässt, der aus der Erweiterung des assert-Makros resultiert. Die Korrekturen führen expressis verbis assert(false && „Unexpected case“) als Beispiel an, das gemäß der neuen Ausnahme konform ist.

Auf den ersten Blick mag MISRA C++:2023 TC1:2026 wie eine routinemäßige redaktionelle Überarbeitung klingen. Sicherlich wurden Formulierungen und Beispiele korrigiert. Aber Entwicklungsteams im Bereich Embedded C++ sollten genauer hinschauen.

Mehrere Aktualisierungen wirken sich auf die Interpretation und Anwendung bestehender Richtlinien aus. Dazu gehören neue Ausnahmen, Änderungen des Analyseumfangs, Klarstellungen zu konformem und nicht konformem Verhalten sowie eine bessere Berücksichtigung moderner C++-Programmierpraktiken.

Diese Unterscheidung wichtig, wenn die MISRA-Konformität durch statische Analyse umgesetzt wird. Die Regelnummern sind gleich geblieben, aber die Art und Weise, wie diese Regeln durchgesetzt werden sollten, hat sich in einigen Fällen geändert. Ein Analysator, der die Korrekturen nicht berücksichtigt, könnte Code markieren, den TC1 nun ausdrücklich zulässt, oder er könnte Verhaltensweisen nicht berücksichtigen, die durch die aktualisierten Leitlinien geklärt wurden. Für Teams, die im Rahmen eines sicherheitskritischen Entwicklungsprozesses auf automatisierte Analysen angewiesen sind, ist die Anpassung an die neueste Auslegung der Richtlinien daher ein wichtiger Bestandteil zur Aufrechterhaltung der MISRA-Konformität.

Warum MISRA C++:2023 TC1 von Bedeutung ist

Programmierstandards entwickeln sich zwangsläufig weiter, wenn sie in der Praxis auf echte Software angewendet werden. Es treten Unklarheiten auf, Beispiele decken Grenzfälle auf und legitime Programmiermuster bedürfen mitunter einer zusätzlichen Klarstellung.

Eine technische Korrektur bietet die Möglichkeit, diese Probleme anzugehen, ohne den zugrunde liegenden Standard zu ersetzen. TC1 tut genau dies für MISRA C++:2023 und liefert die redaktionellen Anweisungen zur Aktualisierung der Richtlinien auf MISRA C++:2023 (TC1:2026). Einige Änderungen sind relativ geringfügig, andere haben jedoch direkte Auswirkungen auf die statische Analyse. So kann ein Konstrukt, das zuvor als Verstoß behandelt wurde, nun unter eine definierte Ausnahme fallen. Andere Änderungen präzisieren wiederum, welche Informationen ein Analysator über das Programmverhalten verstehen muss, um die Konformität korrekt zu bestimmen. Es gibt auch Fälle, in denen sich der erforderliche Analyseumfang selbst geändert hat. Zusammenfassend unterstreichen diese Aktualisierungen einen wichtigen Punkt: Eine sinnvolle MISRA-Unterstützung besteht nicht einfach darin, für jede Regel einen Checker bereitzustellen. Der Checker muss auch die aktuelle Absicht und Semantik der Richtlinie umsetzen.

Wie sich MISRA C++:2023 TC1 im tatsächlichen Code darstellt

Mehrere TC1-Aktualisierungen befassen sich mit Programmierkonstrukten, denen Entwickler:innen im modernen C++-Code regelmäßig begegnen. Eines der einfachsten Beispiele findet sich in Regel 0.0.2, in der TC1 eine Ausnahme einführt, die einen Steuerausdruck zulässt, der aus der Erweiterung des assert-Makros resultiert. Die Korrekturen führen expressis verbis assert(false && „Unexpected case“) als Beispiel an, das gemäß der neuen Ausnahme konform ist.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung
#include <cassert>void handleUnexpectedCase(){    assert(false && "Unexpected case"); // Compliant by TC1 exception}

Dies ist eine kleine Änderung mit praktischen Auswirkungen. Ein Analysator, der die ursprüngliche Auslegung anwendet, ohne die TC1-Ausnahme zu berücksichtigen, könnte fälschlicherweise einen Verstoß für eine Konstruktion melden, die gemäß den aktualisierten MISRA-Richtlinien ausdrücklich zulässig ist. Dies verdeutlicht, warum es wichtig ist, einen Programmierstandard stets auf dem neuesten Stand zu halten. Das Ziel besteht nicht darin, mehr Verstöße zu finden, sondern die richtigen Verstöße zu identifizieren.

Regel 0.1.1 wird wesentlich genauer erklärt. Die Überschrift wurde entsprechend angepasst und lautet nun: „Ein Schreibvorgang auf ein lokales Objekt sollte notwendig sein.“

TC1 definiert außerdem, was einen notwendigen Schreibvorgang ausmacht, basierend auf dem Vorkommen entlang möglicher Ausführungspfade. Die Aktualisierung erkennt zudem [[maybe_unused]] als Ausdruck der Entwicklerabsicht an und klärt die Behandlung von zusammengesetzten Typen, Containern, Schleifen und Funktionen. Diese Unterscheidungen sind wichtig, um Fehlermeldungen zu vermeiden, bei denen der Analysator zwar einen Schreibvorgang technisch identifiziert hat, jedoch nicht korrekt versteht, wie dieser Wert oder dieses Objekt verwendet wird.

Vereinfachtes CRTP-Muster nach MISRA C++:2023 TC1:2026.(Bild:  Parasoft)
Vereinfachtes CRTP-Muster nach MISRA C++:2023 TC1:2026.
(Bild: Parasoft)

Zudem berücksichtigt TC1 etablierte C++-Entwurfsmuster besser. So erhält beispielsweise Regel 6.4.2 eine Ausnahme für das „Curiously Recurring Template Pattern“ (CRTP). In der Korrektur wird ausdrücklich darauf hingewiesen, dass die vorherige Regel die Verwendung des Musters ungerechtfertigt untersagt hat und nun die Namensverbergung unter definierten CRTP-Bedingungen zulässt. Ein vereinfachtes CRTP-Muster sieht ist im angefügten Bild dargestellt.

Dieses Beispiel veranschaulicht das CRTP-Muster, auf das sich die neue Ausnahme bezieht. Das bedeutet jedoch nicht, dass jede Verwendung von CRTP automatisch MISRA-konform ist. TC1 korrigiert vielmehr eine Situation, in der der ursprüngliche Wortlaut eine etablierte C++-Technik verbieten könnte, selbst wenn sie unter den nun durch die Ausnahme definierten Bedingungen verwendet wird.

Regel 6.2.3 wurde in ähnlicher Weise aktualisiert, um sichere, gängige Muster zuzulassen, die explizite Template-Spezialisierungen und die Verwendung von Header-Dateien beinhalten. Zusammen verdeutlichen diese Änderungen einen wichtigen Aspekt von MISRA C++: Sicherheitskritisches C++ bedeutet nicht, moderne C++-Konstrukte zu vermeiden. Vielmehr bedeutet es, diese so einzusetzen, dass sie ausreichend verstanden, eingeschränkt und analysierbar sind, um zuverlässige Software zu gewährleisten.

Präzisere Analyse des C++-Verhaltens

Weitere Änderungen des TC1 befassen sich eingehender mit der Semantik, die ein Analysator verstehen muss. Ein gutes Beispiel hierfür sind numerische Konvertierungen und Vergleiche.

  • So wurde beispielsweise Regel 7.0.3 präzisiert, um „switch“-Anweisungen zu berücksichtigen, und es wurde eine Ausnahme hinzugefügt, die es erlaubt, einen Ausdruck der Zeichenkategorie in den Typ „void“ umzuwandeln, wenn dessen Wert explizit verworfen wird.
  • Regel 7.0.5 stellt klar, dass die Regel für Vergleiche wie „u8 == u8” gilt, wobei anerkannt wird, dass der Vergleich von Werten desselben Typs sicher ist. Außerdem wurden Beispiele korrigiert, die zuvor Fälle von ganzzahliger Aufwertung enthielten. Dies gilt als sicher.

Ein weiterer wichtiger Bereich ist die Behandlung von Objekten, aus denen Daten verschoben wurden. TC1 überarbeitet Regel 28.6.3 grundlegend, um zu klären, wann eine Variable einen potenziell „moved-from“-Zustand aufweist. Dies betrifft Operationen mit std::move, std::forward, std::move_if_noexcept und gleichwertigen Typumwandlungen. Gleichzeitig berücksichtigt die aktualisierte Richtlinie das definierte „Moved-from“-Verhalten von std::unique_ptr, std::shared_ptr und std::weak_ptr.

Genau hier kommt einer ausgefeilten statischen Analyse die entscheidende Bedeutung zu. Es reicht nicht aus, lediglich das Vorhandensein von std::move zu erkennen. Der Analysator muss Folgendes verstehen:

  • Den Zustand der Variablen;
  • Wie anschließend auf sie verwiesen wird; und
  • Ob der Typ eine definierte „Moved-from“-Semantik aufweist.

Das Ziel besteht nicht darin, mehr Befunde zu generieren, sondern die tatsächlich relevanten Befunde zu identifizieren.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Embedded Software Engineering Kongress

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Auch der Analyseumfang spielt eine Rolle

TC1 verdeutlicht zudem, warum eine MISRA-Konformitätsanalyse mitunter einen Blick über die einzelne Quelldatei hinaus erfordert.

Regel 0.2.3 erweitert den erforderlichen Analyseumfang von „Einzelne Übersetzungseinheit“ auf „System“ und behandelt Typen mit eingeschränkter Sichtbarkeit wie private Mitglieder, Typ-Aliase, Vorlagen, Lambda-Closure-Typen, Aufzählungen und anonyme Vereinigungen.

Ein Analysator, der auf eine einzelne Übersetzungseinheit beschränkt ist, verfügt daher möglicherweise nicht über die erforderlichen Informationen, um für diese Regel eine korrekte Entscheidung zu treffen.

Interessanterweise erweitert TC1 den Analyseumfang jedoch nicht einfach überall. So geht beispielsweise Regel 21.6.4 in die entgegengesetzte Richtung und ändert ihren Umfang von „System“ auf „Einzelne Übersetzungseinheit“, während sie gleichzeitig die Anforderungen in Bezug auf globale „delete“-Funktionen mit und ohne Größenangabe präzisiert.

Diese Änderungen unterstreichen, warum ein MISRA-Tool nicht allein anhand der Frage bewertet werden kann, ob es „Regel X“ unterstützt. Aussagekräftiger ist die Frage, ob das Tool die Art der Analyse durchführt, die Regel X tatsächlich erfordert. Korrekte Regelsemantik, Sprachkenntnisse, Daten- und Kontrollflüsse sowie ein angemessener Analyseumfang tragen alle dazu bei, ob ein gemeldetes Ergebnis die MISRA-Richtlinien genau widerspiegelt.

Was bedeutet TC1 also für Ihr statisches Analyse-Tool?

Für Unternehmen, die bereits MISRA C++:2023 einsetzen, wirft TC1 eine klare Frage auf: Behauptet Ihr statisches Analyse-Tool lediglich, MISRA C++:2023 abzudecken, oder spiegelt seine Analyse die neueste Auslegung der Richtlinien wider?

Dieser Unterschied kann praktische Konsequenzen haben. Wenn MISRA eine neue Ausnahme einführt, sollte der Analysator diese erkennen. Wenn TC1 zuvor mehrdeutiges Verhalten klärt, sollte der Prüfer diese Klarstellung anwenden. Wenn sich der Analyseumfang einer Regel ändert, muss sich die zugrunde liegende Analyse entsprechend anpassen. Andernfalls können Entwicklungsteams mit unnötigen Befunden, übersehenen Verstößen, zusätzlichem Aufwand zur Behebung von Abweichungen oder manuellen Überprüfungen konfrontiert werden, um veraltetes Analyseverhalten auszugleichen.

Dies ist besonders wichtig bei sicherheitskritischer Entwicklung, da Ergebnisse der statischen Analyse häufig zu einem größeren Bestand an Nachweisen für die Konformität beitragen. Die Teams müssen sich darauf verlassen können, dass ein gemeldeter Verstoß der aktuellen Richtlinie entspricht und nicht einer Interpretation, die später korrigiert oder präzisiert wurde.

Vollständiger Support für MISRA C++:2023 TC1

Ein Tool wie Parasoft C/C++test unterstützt die durch MISRA C++:2023 TC1:2026 eingeführten relevanten Änderungen in vollem Umfang. Diese Unterstützung geht über die Aktualisierung von Regelbeschreibungen oder der Dokumentation hinaus. C/C++test implementiert die aktualisierte Regelsemantik, Ausnahmen, Analyseanforderungen sowie die in den Korrekturen definierten konformen und nicht konformen Fälle. Diese Unterstützung geht über die Aktualisierung von Regelbeschreibungen oder der Dokumentation hinaus. C/C++test implementiert die aktualisierte Regelsemantik, Ausnahmen, Analyseanforderungen sowie die in den Korrekturen definierten konformen und nicht konformen Fälle.

Dadurch entfällt für Entwicklungsteams die Notwendigkeit, die Überarbeitungen manuell zu prüfen und zu ermitteln, wie sich die einzelnen Änderungen auf die bestehende statische Analyse auswirken. Entwickler können die MISRA-Analyse weiterhin innerhalb ihrer üblichen IDE- und CI/CD-Workflows anwenden und dabei gemäß den neuesten Richtlinien arbeiten. Das reduziert unnötige Nachforschungen zu Befunden, die auf veralteten Interpretationen beruhen, und stellt gleichzeitig sicher, dass neu geklärte Fälle korrekt behandelt werden.

Zudem bindet C/C++test die MISRA-Analyse in den übergeordneten Verifizierungs- und Compliance-Workflow ein. Teams können Verstöße gegen den Codierungsstandard somit früher erkennen, diese im Rahmen der Entwicklung und der CI beheben und die erforderlichen Berichte und Nachweise erstellen. Das Ziel besteht nicht nur darin, einen MISRA-Checker auszuführen, sondern die MISRA-Konformität zu einem wiederholbaren Bestandteil der Softwareentwicklung zu machen.

Aktualisierung der MISRA-C++-Konformität

MISRA C++:2023 TC1 ersetzt MISRA C++:2023 nicht. Es präzisiert die Leitlinien auf der Grundlage von Problemen, die seit der Veröffentlichung der Richtlinien identifiziert wurden. Für Unternehmen, die kritische Embedded Software entwickeln, sind diese Verfeinerungen von Bedeutung, da sich die Präzision des Standards in der Präzision der Analyse widerspiegeln muss, mit der man ihn durchsetzt.

Ein statisches Analyse-Tool muss also mehr verstehen als nur, welche MISRA-Regel gilt. Es muss auch die neueste Auslegung der Regel, Ausnahmen, den erforderlichen Analyseumfang und die zugrunde liegende C++-Semantik berücksichtigen.

Durch die vollständige Unterstützung für MISRA C++:2023 TC1 hilft C/C++test den Entwicklungsteams, ihre MISRA-Analyse auf dem neuesten Stand zu halten und gleichzeitig weiterhin die Vorteile von modernem C++ in sicherheits- und sicherheitskritischer Software zu nutzen.  (sg)

* Ricardo Camacho ist Senior Technical Product Marketing Manager bei Parasoft.

(ID:50998712)