Anbieter zum Thema

Hitex GmbH

Parasoft® Deutschland GmbH

Neue Regeln zu atomic in AMD 4

Die folgenden fünf neuen Regeln (9.7, 11.10, 12.6, 21.25, 21.26) adressieren wie die drei neuen Direktiven das Hauptthema Nebenläufigkeit. Alle Regeln gelten ab dem Sprachstandard C11, da erst in diesem Nebenläufigkeit eingeführt wurde.

Die neue Regel 9.7 (mandatory) fordert, dass atomare Objekte initialisiert sein müssen, bevor auf sie zugegriffen wird. Es ist leicht einzusehen, dass die Verwendung von nicht-initialisierten atomaren Objekten zu einem Datenwettlauf führen kann, was zu undefiniertem Programmverhalten führt, was unbedingt vermieden werden muss. Deshalb ist diese Regel auch mandatory. Es gibt mehrere Möglichkeiten, wie diese Regel einzuhalten ist. Für statische Objekte reicht die Standard-Initialisierung aus, weil diese vor dem eigentlichen Programmstart bei main() stattfindet, und vor main() gibt es noch keine Threads. Für nicht-statische Objekte, beispielsweise Stackvariable, ist es keine Regelverletzung, wenn die Initialisierung mit der Definition erfolgt. Ebenso ist es für solche Variable keine Regelverletzung, wenn die Initialisierung durch die Funktion atomic_init() erfolgt.

Bildergalerie

Allerdings muss atomic_init() vor der Erzeugung von Threads benutzt werden, denn atomic_init() verhindert keinen Datenwettlauf. Die Funktion atomic_init() benötigt den Header <stdatomic.h>. Es ist auch keine Regelverletzung, wenn ein Datenwettlauf durch andere Mechanismen verhindert wird, beispielsweise durch Mutexe.

Die neue Regel 11.10 (required) fordert, dass man den Typ void nicht mit dem Schlüsselwort _Atomic qualifizieren darf. Der Sprachstandard verbietet dies nicht explizit, macht aber andererseits auch keine Zusage, was in so einem Fall genau passieren wird. Somit hat man gegebenenfalls undefiniertes Verhalten, und dies muss vermieden werden.

Die neue Regel 12.6 (required) verbietet den direkten Zugriff auf Elemente von atomaren Objekten vom Typ Struktur oder Union. Solche Zugriffe müssen über spezielle Zugriffsfunktionen wie atomic_init(), atomic_store(), atomic_load(), atomic_exchange() und atomic_compare_exchange() erfolgen. Dadurch gibt es keinen Datenwettlauf; besagte Funktionen haben einen speziellen Mechanismus eingebaut, der dies verhindert. Die Operatoren ‚.‘ (Punkt) und ‚->‘ (Pfeil) dürfen zum Zugriff auf atomare Objekte vom Typ Struktur oder Union nicht verwendet werden.

Die neue Regel 21.25 (required) verlangt, dass alle Memory-Synchronisations-Operationen in der „sequentially consistent“-Reihenfolge (memory_order_seq_cst) ausgeführt werden. Die Memory-Synchronisations-Reihenfolge memory_order_seq_cst ist die default-Reihenfolge und die einzige, die durch den Sprachstandard vollständig definiert ist. Das Verhalten der anderen Reihenfolgen ist nicht portabel, es hängt von der Hardware und dem Compiler ab. Es kann auch zu nicht intuitiv verständlichem Verhalten kommen, beispielsweise bei memory_order_relaxed. Um allen Unabwägbarkeiten aus dem Weg zu gehen, sind die anderen Reihenfolgen verboten. Die Memory-Synchronisations-Reihenfolge wirkt auf die Atomic-Funktionen aus dem Header <stdatomic.h> wie beispielsweise atomic_store(), atomic_load(), usw. Es gibt auch Varianten dieser Atomic-Funktionen wie atomic_store_explicit(), bei denen man die Reihenfolge explizit als Parameter vorgeben kann. Aber auch hier ist nur memory_order_seq_cst für den betreffenden Parameter erlaubt. Das gilt auch für die Atomic-Funktionen atomic_thread_fence() und atomic_signal_fence().

Die neue Regel 21.26 (required) verlangt, dass die Funktion mtx_timedlock() der Standardbibliothek – die nur bis zu einem bestimmten Zeitpunkt wartet, um einen Mutex zu erhalten – nur mit Mutex-Objekten vom passenden Typ aufgerufen werden. Es ist nämlich undefiniertes Verhalten, wenn diese Funktion auf ein Mutex-Objekt angewandt wird, das keinen Timeout unterstützt. Es muss ein Mutex-Objekt vom Typ mtx_timed oder (mtx_timed | mtx_recursive) sein.

Neue Regeln zu Threads in AMD4

Zehn neue Regeln (Regel 22.11 bis 22.20) behandeln Threads. Threads sind separate leichtgewichtige Ausführungsstränge innerhalb eines Programms. Die neuen Regeln sind nicht schwer zu verstehen; sie fordern lediglich den vernünftigen Umgang mit Threads. Alle Regeln gelten ab C11, da es Threads vorher nicht gab. Alle Regeln haben die Verbindlichkeit mandatory oder required.

Die neue Regel 22.11 (required) fordert, dass ein Thread, der bereits eine Join-Operation oder eine Detach-Operation für einen anderen Thread ausgeführt hat, nicht nochmals eine der beiden Operationen für den anderen Thread ausführen darf; ansonsten entsteht undefiniertes Verhalten. Durch eine Join-Operation wird der aktuelle Thread blockiert, bis der andere Thread beendet ist. Durch eine Detach-Operation wird ein Thread vom aktuellen Prozess losgelöst.

Die neue Regel 22.12 (mandatory) fordert, dass auf Thread-Objekte, Thread-Synchronisations-Objekte (Mutexe) und thread-spezifische Speicher-Pointer nur mit den passenden Funktionen der Standard-Bibliothek zugegriffen werden darf. Diese Funktionen haben die Präfixe thrd_, mtx_, cnd_ und tss_. Wenn man verbotenerweise Thread-Objekte direkt manipuliert, beispielsweise einander direkt zuweist, kann undefiniertes Verhalten entstehen.

Die neue Regel 22.13 (required) fordert, dass Thread-Objekte, Thread-Synchronisations-Objekte (z.B. Mutexe) und thread-spezifische Speicher-Pointer eine geeignete Speicherdauer haben müssen. Anders ausgedrückt heißt dies, dass solche Objekte weder automatische Speicherdauer (beispielsweise bei Stack-Objekten) noch thread-lokale Speicherdauer haben dürfen. Was passiert, wenn auf ein nicht mehr vorhandenes solches Objekt zugegriffen wird, ist undefiniertes Verhalten und das muss vermieden werden. Empfohlen wird, einen statischen Pool solcher Objekte zu verwenden.

Die neue Regel 22.14 (mandatory) fordert, dass Thread-Synchronisations-Objekte vor ihrer Verwendung initialisiert werden müssen. Das muss durch die Funktionen mtx_init() oder cnd_init() geschehen.
Die neue Regel 22.15 (required) fordert, dass alle Thread-Synchronisations-Objekte und thread-spezifische Speicher-Pointer nicht zerstört werden dürfen, solange nicht alle Threads, die auf sie zugreifen, beendet sind.
Die neue Regel 22.16 (required) fordert, dass alle Mutex-Objekte, die von einem Thread belegt (lock) werden, auch von diesem Thread wieder freigegeben (unlock) werden.
Die neue Regel 22.17 (required) fordert, dass ein Thread einen Mutex nur freigeben (unlock) darf oder cnd_wait() oder cnd_timedwait() aufrufen darf, wenn dieser Thread den Mutex vorher belegt (lock) hat.
Die neue Regel 22.18 (required) fordert, dass nicht-rekursive Mutexe nicht rekursiv belegt (lock) werden dürfen. Rekursive Mutexe sind solche, die mit dem Parameter mtx_recursive initialisiert wurden. Diese kann man mehrfach belegen und freigeben.
Die neue Regel 22.19 (required) fordert, dass eine Condition-Variable mit höchstens einem Mutex-Objekt assoziiert sein darf.
Die neue Regel 22.20 (mandatory) fordert, dass thread-spezifische Speicher-Pointer erzeugt sein müssen, bevor auf sie zugegriffen wird. Die Erzeugung erfolgt mittels der Funktion tss_create().

Neue Regeln in AMD 4 ohne Bezug zur Nebenläufigkeit

Vier neue Regeln befassen sich nicht mit Nebenläufigkeit, sondern behandeln Themen der C-Sprachstandards vor C11. Das sind die Regeln 2.8, 7.6, 9.6 und 18.10.

Die neue Regel 2.8 (advisory) befasst sich mit unbenutzten Objekten. Ein Objekt, beispielsweise eine Variable, ist unbenutzt, wenn man die Definition (und gegebenenfalls alle vorhandenen Deklarationen) entfernen kann, und das Programm trotzdem übersetzt und gelinkt werden kann. Regel 2.8 fordert, dass ein Projekt keine unbenutzten Objekte enthalten soll. Die Regel zielt schlicht auf bessere Verständlichkeit des Programms. Diese Regel gilt ab C90 [C90]. Weil unbenutzte Objekte keine direkte Gefahr für die funktional korrekte Programmausführung bedeuten, ist diese Regel advisory.

Die neue Regel 7.6 (required) fordert, dass die Varianten für kleine Ganzzahlen der Mindestbreite-Ganzzahlen-Konstanten-Macros (minimum-width integer constant macros), beispielsweise UINT8_C(), nicht benutzt werden dürfen. Das Verbot ist dadurch begründet, dass diese Macros nicht immer bewirken, was man auf den ersten Blick annehmen könnte. Regel 7.6 ist required und gilt ab C99.
Um Regel 7.6 zu verstehen, muss man in die Tiefen der Programmiersprache C hinabsteigen. Solche Macros expandieren zu einem Ganzzahlausdruck mit einem bestimmten Typ; beispielsweise UINT8_C() zu uint_least8_t, was der kleinste Ganzzahltyp mit mindestens 8 Bit ist. Solche Macros expandieren aber auch zu einem Ganzzahlausdruck, der in einer #if-Präprozessor-Direktive verwendet werden kann und deshalb ist der resultierende Typ derselbe Typ wie nach einer Integer-Promotion.

Bild 3 zeigt einen Code-Schnipsel (oben) und die von diesem Code-Schnipsel erzeugte Ausgabe (unten, blau unterlegt). Die Größe des Datentyps uint8_t wie auch die Größe der Variablen a ist wie erwartet ein Byte. Überraschend ist die Größe von UINT8_C(99), die vier Bytes ist, obwohl der Wert 99 in ein Byte passen würde. Der verwendete Compiler (MinGW gcc V9.2.0) verwandelt das Macro aber in ein signed integer und das ist bei diesem Compiler eben vier Bytes groß. Um solchen Überraschungen vorzubeugen, verbietet Regel 7.6 die Benutzung von UINT8_C().

Die neue Regel 9.6 (required) verbietet bei Initialisierungen mit verketteten Bezeichnern, dass sie auch Initialisierungen ohne Bezeichner haben. Verkettete Bezeichner kann man verwenden, um bei der Initialisierung eines Objekts (beispielsweise einer Struktur), welches ein Sub-Objekt hat, Bestandteile des Sub-Objekts zu initialisieren. Das ist vor allem nützlich, wenn nur ein einzelnes Element eines größeren Objekts initialisiert werden soll; alle anderen Elemente werden dann automatisch auf 0 gesetzt, so wie wenn das Objekt ein statisches Objekt wäre. Man muss bei der Initialisierung aber keine Bezeichner verwenden, man kann auch positionsbezogen initialisieren. Gefährlich wird es, wenn man beide Methoden mischt, denn es ist dann nicht immer offensichtlich, wie schlussendlich jedes Element des Objekts initialisiert ist. Regel 9.6 gilt ab C99.

Die neue Regel 18.10 (mandatory) besagt, dass Pointer auf variably-modified Arrays verboten sind. Variably-modified Arrays waren bisher in der bestehenden Regel 18.8 miterfasst; von dieser Regel werden sie nun explizit ausgeschlossen. Der Hintergrund des Verbots in Regel 18.10 ist, dass bei der Übersetzung des Codes der Element-Typ eines variably-modified Arrays naturgemäß nicht bekannt ist. Deswegen kann zur Übersetzungszeit auch nicht geprüft werden, ob ein Pointer auf ein variably-modified Array kompatibel zu einem anderen Pointer auf ein Array ist, falls dies notwendig sein muss, beispielsweise bei einer Zuweisung. Somit läuft man Gefahr, dass zur Laufzeit inkompatible Pointer einander zugewiesen werden, und das ist undefiniertes Verhalten. Dies muss vermieden werden; deshalb das Verbot von Pointern auf variably-modified Arrays. Regel 18.10 gilt ab C99.

Anpassungen von bereits vorhandenen Regeln in AMD 4

Die beiden vorhandenen Regeln 11.3 und 11.8 werden wegen des neuen Schlüsselworts _Atomic angepasst.

Neben der Benutzung des Ausdrucks Konvertierung (conversion) statt cast werden in Regel 11.3 atomare Objekte von der Ausnahme zu dieser Regel explizit ausgeschlossen. Die Ausnahme gilt also nur für nicht-atomare Objekte.

Regel 11.8 fordert nun zusätzlich, dass man durch eine Konvertierung die _Atomic-Qualifikation nicht von einem Objekt entfernen darf. Das galt bisher schon für const und volatile, und nun auch für _Atomic. Durch das (wahrscheinlich unbeabsichtigte) Entfernen der _Atomic-Qualifikation entsteht aus einem atomaren Objekt ein normales Objekt; dadurch kann Datenwettlauf entstehen, und dies ist undefiniertes Verhalten und muss vermieden werden.

Die bereits vorhandenen Regeln 13.2 und 18.6 werden wegen Aspekten der Nebenläufigkeit angepasst.

Regel 13.2 wird dahingehend erweitert, dass der Wert eines Ausdrucks (und seiner persistenten Seiteneffekte) nicht nur wie bisher unabhängig von der Evaluierungsreihenfolge sein muss, sondern neu nun auch zusätzlich unabhängig von der Verzahnung von Threads.

Regel 18.6 forderte schon bisher, dass die Adresse eines Objekts mit der Speicherklasse automatisch (also beispielsweis ein Stack-Objekt) nicht auf ein anderes Objekt kopiert werden darf, das noch existiert, wenn das erste Objekt aufgehört hat zu existieren. Dies wird nun auch zusätzlich für thread-lokale Objekte gefordert.

AMD 4 enthält auch ein Technical Corrigendum

Die technischen Korrekturen betreffen neue Erklärungen in Abschnitt 6.9, wo es um die Darstellung der Vorgaben geht und acht Korrekturen in den Regeln 2.2, 2.7, 3.1, 8.6, 8.9, 9.4, 10.1 und 18.3. Die meisten dieser Korrekturen sind unwesentlich, vielleicht mit Ausnahme von Regel 3.1 und 9.4.

In den Regeln 2.2 und 2.7 werden die Regelüberschriften an Überschriften von anderen Regeln angepasst, ohne dass sich inhaltlich was ändert.
In Regel 3.1, die den Kommentarbeginn „//“ (doppelte Schrägstriche) in Kommentaren verbietet, wird nun als Ausnahme „//“ in Kommentaren zugelassen, wenn „//“ Teil einer Web-Adresse, genauer eines Uniform Resource Identifiers (URI), ist.

Regel 8.6 wird um einen Verweis auf Regel 8.15 ergänzt. Regel 8.15 wurde in AMD 3 eingeführt und hat selbst einen Verweis auf Regel 8.6, aber der Verweis in die umgekehrte Richtung (Regel 8.6 auf Regel 8.15) wurde in AMD 3 vergessen.
In Regel 8.9, die es schon in MISRA C:2012 gab, werden alle Vorkommen von „defined“ durch „declared“ ersetzt.

Regel 9.4, die es schon in MISRA C:2012 gab, wird um Erläuterungen und ein Beispiel zu bezeichneten Initialisierungen (designated initializers) erweitert. Mit bezeichneten Initialisierungen kann man beispielsweise die Elemente einer Struktur initialisieren, wenn man dabei aber nicht aufpasst, werden eventuell bereits initialisierte Elemente überschrieben. Dabei ist auch unklar, ob mögliche Seiteneffekte der überschriebenen Initialisierung eintreten oder nicht. Deshalb verbietet Regel 9.4 mehrfache Initialisierungen. Regel 9.4 verweist nun auch auf die neue Regel 9.6 aus AMD 4.

In den beiden Regeln 10.1 und 18.3 wird der Begriff „objects“ durch den Begriff „expressions“ ersetzt. Regel 10.1 gab es schon in MISRA C:2012, in AMD 3 kam Ausnahme 2 hinzu, und in AMD 4 wird in dieser Ausnahme 2 der Begriff „objects“ durch „expressions“ ersetzt. Regel 18.3 gab es auch schon seit MISRA C:2012, die Ersetzung der Begriffe betrifft die Überschrift der Regel.

AMD 4 enthält auch Folgeänderungen (consequential amendments)

Vier Regeln müssen geändert werden, als Folge der Änderungen in AMD 4. Dies sind die Regeln 1.4, 7.5, 9.1 und 9.2.
Die Regel 1.4 kam in AMD 2 neu dazu und verbietet neue Sprachfeatures. Dazu gehörten bis zu AMD 4 auch atomare Objekte und Threads. Diese werden in AMD 4 behandelt, und somit entfällt Ihr Verbot in Regel 1.4.
Regel 7.5 kam in AMD 3 neu hinzu und erhält nun einen Verweis auf die neue Regel 7.6 in AMD 4.
In Regel 9.1 werden atomare Objekte ausgeschlossen, weil diese in der neuen Regel 9.7 in AMD 4 behandelt werden.
Regel 9.2 wird um einen Hinweis auf Regel 9.6 ergänzt.

Erweiterung von Addendum 3

Sowohl AMD 3 als auch AMD 4 erweitern Addendum 3 [MISRA-AD3]. Addendum 3 vergleicht die MISRA-Vorgaben mit dem SEI-CERT-C-Coding-Standard – in der Ausgabe von 2016 – für sicheres (secure) Programmieren. Mit AMD 1, AMD 3 und AMD 4 zusammen werden nun schlussendlich 93 der 99 Vorgaben – also 94 Prozent – aus CERT durch Vorgaben aus MISRA abgedeckt, allerdings manche nur teilweise. Trotzdem decken die mehr mit Safety assoziierten Vorgaben aus MISRA auch gut die explizit für Security gedachten Vorgaben von CERT ab.

Nach 25 Jahren: Bündelung in einem Dokument

Sehr kurz nach dem Erscheinen von AMD 4 konsolidiert MISRA die vier Amendments und die zwei technischen Korrekturdokumente zu MISRA C:2012 in eine neue Version von MISRA, die den Namen MISRA C:2023 [MISRA4] erhält. Eigentlich müsste dies die vierte Ausgabe von MISRA sein, aber im Zusatz auf der Titelseite wird MISRA C:2023 als dritte Ausgabe, zweite Revision bezeichnet, siehe Bild 4. Dies ist nun wenig stringent, aber weil MISRA C:2023 keine Restrukturierung von MISRA C:2012 ist, sondern eine inkrementelle Weiterentwicklung, und um das 25jährige Jubiläum zu würdigen, hat sich MISRA zu dieser Bezeichnung entschlossen.

MISRA C:2023

MISRA C:2023 ist ein wichtiger Schritt in der Entwicklung der MISRA-Richtlinien, denn es erleichtert die Arbeit mit den Vorgaben enorm. Wollte man bisher Genaues zu einer bestimmten Vorgabe wissen, musste man ein halbes Dutzend Dokumente – die Amendments und Technical Corrigenda – durchsuchen. Nun ist alles in einem Dokument zusammengefasst. Zudem sind die MISRA-Vorgaben nun auch für Projekte anwendbar, die konform zu C11 bzw. C18 sind. Das heißt jedoch nicht, dass MISRA C:2023 irrelevant für Projekte nach den älteren Sprachstandards C90 und C99 sind, denn MISRA C:2023 enthält auch neue und geänderte Regeln für diese Sprachstandards.

Verfügbarkeit

Alle Amendments und weiteren Dokumente können kostenlos von der MISRA-Internetseite (www.misra.org.uk) abgerufen werden. MISRA C:2023 gibt es als PDF-Version, diese kostet 15 GBP für einen Nutzer und als gedruckte Version (Print-on-demand), diese kostet 45 GBP.

Literatur- und Quellenverzeichnis

[C90] ISO/IEC 9899:1990, Programming languages – C, International Organization for Standardization, 1990.

[C99] ISO/IEC 9899:1999, Programming languages – C, International Organization for Standardization, 1999.

[C11] ISO/IEC 9899:2011, Programming languages – C, International Organization for Standardization, 2011.

[C18] ISO/IEC 9899:2018, Programming languages – C, International Organization for Standardization, 2018.

[CERT] SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems, 2016th ed. Software Engineering, Carnegie Mellon University, 2016.

[MISRA] www.misra.org.uk MISRA ist ein Handelsname von The MISRA Consortium Limited und steht in dieser Veröffentlichung für beides.

[MISRA1] MISRA C:1998, Guidelines for the use of the C language in vehicle based software, Horiba Mira Limited, UK, April 1998.

[MISRA2] MISRA C:2004, Guidelines for the use of the C language in critical systems, Horiba Mira Limited, UK, Edition 2, Oktober 2004.

[MISRA3] MISRA C:2012, Guidelines for the use of the C language in critical systems, Mira Limited, UK, Edition 3, März 2013.

[MISRA3R1] MISRA C:2012, Guidelines for the use of the C language in critical systems, Horiba Mira Limited, UK, Edition 3, Revision 1, Feb. 2019.

[MISRA4] MISRA C:2023, Guidelines for the use of the C language in critical systems, The MISRA Consortium Limited, UK, Edition 3, Revision 2, April 2023.

[MISRA-AMD1] MISRA C:2012 Amendment 1 — Additional security guidelines for MISRA C:2012. Horiba Mira Limited, UK, Apr. 2016.

[MISRA-AMD2] MISRA C:2012 Amendment 2 — Updates for ISO/IEC 9899:2011 Core functionality. Horiba Mira Limited, UK, Feb. 2020.

[MISRA-AMD3] MISRA C:2012 Amendment 3 — Updates for ISO/IEC 9899:2011/2018 Phase 2. The MISRA Consortium Limited, UK, Okt. 2022.

[MISRA-AMD4] MISRA C:2012 Amendment 4 — Updates for ISO/IEC 9899:2011/2018 Phase 3. The MISRA Consortium Limited, UK, März 2023.

[MISRA-AD2] MISRA C:2012 Addendum 2 — Coverage of MISRA C:2012 (including Amendment 1) against ISO/IEC TS 17961:2013 “C Secure”, 2nd ed. Horiba Mira Limited, UK, Jan. 2018.

[MISRA-AD3] MISRA C:2012 Addendum 3 — Coverage of MISRA C:2012 (including Amendment 1) against CERT C 2016 Edition. Horiba Mira Limited, UK, Jan. 2018.

[MISRA-COM2] MISRA Compliance:2020 — Achieving compliance with MISRA Coding Guidelines. Horiba Mira Limited, UK, Feb. 2020.

[MISRA-TC1] MISRA C:2012 Technical Corrigendum 1 — Technical clarification of MISRA C:2012. Horiba Mira Limited, UK, Juni 2017.

[MISRA-TC2] MISRA C:2012 Technical Corrigendum 2 — Technical clarification of MISRA C:2012. The MISRA Consortium Limited, UK, Feb. 2022.

Der Autor

Frank Büchner hat ein Diplom in Informatik von der Technischen Hochschule Karlsruhe, heute Karlsruher Institut für Technologie (KIT). Seit mehr als zwanzig Jahren widmet er sich dem Thema Testen und Software-Qualität. Gerne gibt er sein Wissen durch Artikel, Vorträge und Webinare weiter. Momentan arbeitet er als „Principal Engineer Software Quality“ bei der Fa. Hitex GmbH in Karlsruhe. (mbf)

(ID:49861959)