Kritik an MISRA-C

MISRA-C (Motor Industry Software Reliability Association) ist ein Programmierstandard aus der Automobilindustrie für die Programmiersprache C.

Der Misra-Standard besteht aus den sogenannten Misra-Regeln. 1998 erschienen 127 (93+34) Regeln, 2004 141 (121+20) Regeln und 2012 (C99) 143 Regeln und 16 Direktiven. Diese Regeln wurden erarbeitet auf Basis von Fehlern von C-Programmierern. Die Regeln bestehen aus Verboten und Nichtverwendungsempfehlungen von C-Sprachmitteln. Misra will durch die Beachtung der Regeln erreichen, daß C-Programme nun sicherer programmiert werden, so daß einer Verwendung in sicherheitskritischer Umgebung (SIL1 .. SIL4) nichts mehr im Wege steht.

Wikipedia   HIS subset (Misra1998)   Misra:2004   Misra:1998
misra.org   misra-c2.com

Die Misra-Regeln verbieten eigentlich alles, was C ausmacht:

Dies ist eine absichtliche Schimpftirade, die aber nicht im Blutrausch geschrieben wurde. Ein sehr guter C-Programmierer erkennt nach einigen Minuten des Lesens einer Misra-Regel-Liste, welch großen Schaden die Befolgung dieser Regeln bewirkt. Siedend heiß steigt die Wut auf, wenn klar wird, daß auch noch Geld dafür bezahlt wird, großen Schaden erleiden zu dürfen. Die nachfolgend aufgeführten Links zeigen ungefähr 50 Berichte und Kommentare kontra Misra. Es wird klar - glasklar - daß Misra-C tatsächlich massiv schädlich und grober Unfug ist - befördert von großer Inkompetenz!

Kritik in der Newsgroup de.comp.lang.c
Kritik im heise-Forum
Beweiskräftige Beispiele
Kritik-Webseite
Kritik in einem Forum
Kritik und Informationen an einer Hochschule
Oje-Effekt (Foren-Beiträge)
Kritik in einem C-Forum

Kritik an dieser Kritik-Seite

Nachfolgend gilt Standard MISRA-C:2004, der sich auf C90 bezieht.

Eine größere Anzahl von Regeln ist mit zu wenigen Worten unklar, mißverständlich, verwirrend festgelegt worden:

Kritisierte MISRA-Regeln (41)

Die MISRA-Regeln sind entstanden aufgrund von Fehlern, die von C-Programmierern gemacht wurden. Diese Zusammenstellung ist ein Verdienst von MISRA. Die Art der aktuellen Verwendung dieser statistischen Resultate ist jedoch im Endeffekt wahrscheinlich nicht nützlich, sondern schädlich.

Die Fehler, die im Einzelnen und im Gesamten bewertet, von den betrachteten C-Programmierern gemacht wurden, deuten zwingend darauf hin, daß es sich um Programmierer handelt, die C weitgehend nicht beherrschen, die folglich Dilettanten sind.

Es schält sich heraus, daß von Seiten Misra und deren Anwendern beabsichtigt ist und gehofft wird, daß mit Hilfe der Misra-Regeln nun auch Dilettanten sicherheitsrelevanten C-Code schreiben können und sollen. Holla - da geht einem das Herz in der Hose auf! Dilettanten sollten niemals an sicherheitskritischen Code herangelassen werden - weder mit noch ohne Misra-Regeln! Ein Programmierer, der solche und ähnliche Hilfen benötigt, ist von Grund auf ungeeignet, sicherheitskritischen Code zu entwickeln. Die einzige Hilfe soll ein guter Compiler mit vielen implementierten Hinweis-, Warn- und Fehlermeldungen sein, und/oder vergleichbare Werkzeuge.

Wenn diese lange Liste von MISRA-Regeln (41 von über 140) mit C-Sachverstand gelesen wird, kommt zuerst Verwunderung auf, die nach einer Weile des Lesens in blankes Entsetzen umschlägt. Es ist durchaus möglich, über 30 Jahre C-Programmierung zu betreiben und nicht einen einzigen Fehler zu begehen, der im Zusammenhang mit irgendeiner MISRA-Regel und deren Begründung steht! Das heißt, es ist niemals ein Fehler passiert, aufgrund von mangelndem Verständnis eines Sprachmittels der Programmiersprache C. Es wurden eben - ganz einfach - Sprachmittel solange nicht eingesetzt, solange sie nicht vollkommen verstanden waren. Oder die Sprachmittel wurden nur insoweit ausgeschöpft wie es zum jeweiligen Kenntnisstand paßte. Fehler anderer Art sind durchaus zu Hunderten passiert. Nämlich Algorithmus-Fehler: Es wurden (kreative) Überlegungen vergessen oder falsch angestellt. Und genau zur Minimierung von Algorithmus-Fehlern ist das vollständige Ausschöpfen aller Sprachmittel geeignet.

Die Erschaffer von Programmiersprachen haben ganz sicher jedes Sprachmittel genauestens überlegt, weil sie wissen, was wie benötigt wird, um im jeweiligen Rahmen alle Programmierprobleme möglichst zügig, effizient, elegant und übersichtlich lösen zu können. Bei Befolgung aller MISRA-Regeln jedoch wird die Sprache C so stark reduziert, daß es sich nicht mehr um eine leistungsfähige Programmiersprache handelt. Es müssen schlechtere Konzepte verwendet und der Quellcode unübersichtlich aufgeblasen werden, um die fehlenden Sprachmittel zu ersetzen. Es fehlt der Raum für Kreativität - man kämpft mit dem Wust. Es ist zu bezweifeln, daß dies zu sichereren Programmen führt. Außerdem sind solche Programme zur Laufzeit oft beträchtlich weniger performant, bis hin zur Unbrauchbarkeit.

Die Sprachen ADA und PEARL werden für sichere Programmierung empfohlen. Beide Sprachen stellen beispielsweise RETURN; als auch RETURN (expr); zur Verfügung, mit den gleichen vielfältigen Verwendungsmöglichkeiten wie in C. ADA enthält auch goto und exit (break), wobei eine exit-Anweisung auch aus beliebig vielen verschachtelten Schleifen herausspringen kann. Jedoch hier gibt es keinerlei Verbote, um Sicherheit zu gewährleisten. Diese Sprachen sind für sichere Programmierung geeignet, unter anderem gerade wegen ihrer vorhandenen Sprachmittel.

Es ist grundlegend, daß die Wahrscheinlichkeit von Softwarefehlern mit der Gesamtmenge und mit den Teilmengen an Codezeilen steigt. Je komplexer und unübersichtlicher ein Quellcode(teil) ist, desto wahrscheinlicher sind Fehler darin. Umgekehrt ist schlanker und übersichtlicher Code potentiell sicherer. Des Weiteren waren in der Vergangenheit weit überwiegend Algorithmus-Fehler (versäumte oder falsche Überlegungen) Ursache von Schäden durch fehlerhafte Software (Bugs, Ariane, Therac-25). Die Befolgung aller MISRA-Regeln verursacht (indirekt) potenziell unsicherere Software. Verwender unterliegen dem gefährlichen Trugschluß, daß ihre Software allein durch Befolgung der MISRA-Regeln sicher oder sicherer ist. Verwendungsverbot von Sprachmitteln ist hier ein falscher Ansatz. Die stärkste positive Wirkung bezüglich Sicherheit wird erzielt, wenn beim Schreiben eines jeden Codeabschnittes dessen Aufgaben und Wechselwirkungen gründlichst von einem erfahrenen und talentierten Programmierer überlegt und berücksichtigt werden und dieser Programmierer die verwendete Programmiersprache meisterhaft beherrscht und verwendet und die Hardware-Plattform sehr gut kennt.

Die Fortentwicklung der Misra-Regeln über einen langen Zeitraum (1998, 2004, 2012) zeigt notwendige Neudefinitionen, Definitionsmodifikationen und Präzisierungen von Regeln und Bildung ganz neuer Kategorien. Das ist positiv und gleichzeitig auch negativ zu bewerten. Negativ, da offenbar lange Zeit mit mangelhaftem Regelwerk gearbeitet wurde. Vielfach wird immer noch mit den Regeln_2004 oder gar 1998 gearbeitet. Es hinkt alles sehr hinterher, auch hinter den C-Standards. Die Situation bei den Tools für Misra-C ist ähnlich. Die Qualität dieser Tools ist schwer prüfbar. Eine konkrete Erfahrung mit dem Misra-Modus eines C-Compilers liegt vor: Im Misra-Modus hatte der Compiler eine große Anzahl von Regel-Verstößen in den mitgelieferten Header-Dateien angezeigt und die Kompilierung verweigert. Verbesserungen gegenüber MISRA-C:2008 Was dort über die Regelwerke und Tools geschrieben steht, erweckt kein Vertrauen. Nur etwa 107 Regeln werden vom Compiler oder Linker automatisch berücksichtigt. Die Misra-Regeln erzwingen verklausulierten, seltsam verrenkten, affig geschraubten Code. Solch eine Situation ist im Zusammenhang mit Sicherem Code unerwünscht. Viel sicherer und insgesamt vorteilhafter wäre es, einfach C zu lernen, und dem ganzen Misra-C-Ballast konsequent aus dem Weg zu gehen.

Ein prominenter C-Experte, der nicht genannt werden wollte, hat 2001 gesagt: "MISRA C is a shack built on a swamp!" (Misra ist eine Bretterbude, gebaut auf Sumpf.)

Misra-C wurde geschaffen und existiert nur für Embedded Programmierung in der Automobilbranche. Das ist u.a. daran erkennbar, daß <stdio.h> verboten ist, das in anderen Bereichen fast immer unverzichtbar ist. Dennoch gilt auch in anderen Bereichen vermehrt: Wenn C, dann Misra-C. Welch ein Schwachsinn! Dies wird offenbar ebenfalls von inkompetenten Leuten angetrieben. Da müssen dann auf Antrag Regeln gebrochen werden; jemand Anderes hatte dazu mal mit Recht gesagt: Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist unzulaenglich und somit auch unsinnig. (Siehe auch oben: Bretterbude / Sumpf.)
Es hat durchaus eine Berechtigung, auf Microcontrollern gepufferte Ausgabe mittels printf() oder fprintf() zu unterbinden. Manche Compiler/Betriebssysteme bieten z.B. eine abgespeckte iprintf() an, die zur seriellen Schnittstelle schreibt. Dagegen ist nichts zu sagen, wenn sie außerhalb von Interrupt-Handlern aufgerufen wird.
Beim Verbot von <stdio.h> wurde wohl übersehen, daß einige nützliche Funktionen dadurch deklariert werden, die mit einem RAM-Puffer arbeiten, also keine Ausgabe/Eingabe zu/von einem Gerät vornehmen und auch nicht gepuffert sind: Es gibt keinen Grund, z.B. sprintf() und sscanf() zu verbieten.