Fakten zu MISRA-C
Was ist MISRA?
Das MISRA-Konsortium (Motor Industry Software Rekiability) ist eine englische Organisation von Automobilherstellern, welche sich zusammengesetzt haben, um Regeln f�r die unsichere Programmiersprache C aufzustellen.
Ziel
Ziel ist es, Programmierfehler in sicherheitskritischen Bereichen, wie z. B. Der Automobilbranche, zu minimieren.
Vorl„äufer
Vorl„äufer von MISRA-C sind die 1994 vom MISRA-Konsortium ver"ffentlichten MISRA-Guidelines, welche allgemeine Richtlinien f�r die Erstellung von Software beschrieben.
historische Entwicklung
- 1994: Herausgabe der MISRA-Guidelines, dem Vorl„ufer von MISRA-C
- es folgten viele diverse Konferenzen zu Themen wie Sicherheit und Qualit„tssicherung
- 1995: Meilenstein war das Buch von Les Hatton "Safer C" (siehe unten)
- 1998: Herausgabe von MISRA-C
- 2004: Aktualisierung und Herausgabe von MISRA-C 2 (entspricht MISRA-C-2004)
MISRA Guidelines
- enth„lt allgemeine Richtlinien f�r die Erstellung von Software
- befasst sich mit dem gesamten Lebenszyklus von Software
MISRA-C
- entstanden 1998
- enth„lt insgesamt 127 Regeln
- h„lt sich logischerweise auch an bestehende ISO-Normen
- enth„lt neben allgemeinen Richtlinien spezielle Kodierrichtlinien
- Klassifizierung von Fehlern in vier Bereiche
- Erkennen von empirischen Programmierfehlern
1.1.1 Nachteile:
- sehr teuer (mehrere tausend Euro)
- flache Struktur = keine Gliederung
1.1.1 Kritische Aspekte von C
1.1.1.1 Unspezifisches Verhalten
- Betrifft korrekte Programmkonstrukte, f�r die der C-Standard keine Bedingungen stellt.
- Erlaubt dem Sprachimplementierer/Hersteller eine gewisse Freiheit, wie er das Feature implementiert. Das Programm wird aber immer noch �bersetzt (kein Fehler).
- Beispiele:
- Evaluierungsreihenfolge bestimmter Ausdr�cke
- Repr„sentation von float-Zahlen
1.1.1.1 Undefiniertes Verhalten
- Betrifft ung�ltige Programmkonstrukte, f�r die der C-Standard keine Bedingungen stellt.
- Erlaubt dem Sprachimplementierer/Hersteller gewisse Fheler zu ignorieren, die schwer zu finden w„ren. Programm wird aber immer noch �bersetzt (kein Fehler).
- Beispiele:
- Bei einem Funktionsaufruf entspricht das aktuelle Argument nicht dem formalen Typ.
- Ein Bezeichner verweist innerhalb der gleichen šbersetzungseinheit sowohl innerhalb einer Datei als auch datei�bergreifend auf ein Objekt (internal und external linkage).
- Das Programm redefiniert einen external Bezeichner.
1.1.1.1 Implementierungsbedingtes Verhalten
- Betrifft Programmkonstrukte, die der Hersteller auf propriet„re Weise implementieren kann.
- Da diese F„lle dokumentiert werden, sind sie "nur" beim Wechsel von Compiler/Plattform kritisch (bzw. der Entwickler muss erneut die Herstellerdokumentation studieren).
- Beispiele:
- Anzahl der signifikanten Zeichen in einem Bezeichner k"nnen Eindeutigkeit verhindern (ohne external linkage: n>31; mit external linkage: n>6)
- Die Frage, ob ein einfacher char-Datentyp den gleichen Wertebereich wie ein signed oder unsigned char hat.
1.1.1.1 Durch L„nderspezifika vorgegebenes Verhalten
- Programmkonstrukte, die sich je nach Land unterscheiden
- Beispiele:
- Zeichensatz, Richtung, in der geschrieben/gedruckt wird
- Zeichen f�r die Formatierung/Trennung von Zahlen (Tausenderpunkt)
Quelle:iX 2/2006
, Seite 54
MISRA-C-2004
- enth„lt insgesamt 141 Regeln
- Unterscheidung in 121 erforderlichen (required) und 20 empfohlenen (advisory) Regeln
- *kosteng�nstig*: f�r ein paar Euro auf der Website von MISRA (http://www.misra.org.uk) erwerbbar
1.1.1 Žnderungen von MISRA-2004:
- Gliederung nach dem Prinzip: "eine Regel, ein Issue", ggf. weitere Untergliederung
- Zuordnung in 21 Kategorien
- Verweise untereinander (Cross-Referenzen)
- Code-Beispiele hinzugef�gt bzw. verbessert
- Einsatz eines Werkzeuges zur šberpr�fung der Regeln ist verpflichtend
- Referenzierung des SIL (Safety Integrity Level aus IEC 61508) wurde entfernt
1.1.1.1 Kategorien der MISRA-C-2004-Regeln
Kat-Nr.|Name|#required|#advisory
1.|Environment|4|1
2.|Language Extensions|3|1
3.|Documentation|5|1
4.|Character Sets|2|0
5.|Identifiers|4|3
6.|Types|4|1
7.|Constants|1|0
8.|Declarations and Definitions|12|0
9.|Initialisation|3|0
10.|Arithmetic Type Conversion|6|0
11.|Pointer Type Conversion|3|2
12.|Expressions|9|4
13.|Control Statement Expressions|6|1
14.|Control Flow|10|0
15.|Switch Statements|5|0
16.|Functions|9|1
17.|Pointers and Arrays|5|1
18.|Structures and Unions|4|0
19.|Preprocessing Directives|13|4
20.|Standard Libraries|12|0
21.|Run-time Failures|1|0
Quelle:iX 2/2006, Seite 58
1.1.1 Handhabung in der Praxis
- gleichzeitiger Einsatz aller Regeln nicht zweckm„ ig (einige F„lle erfordern Einsatz bestimmter Datentypen oder Konstrukte)
- "Deviation Procedure" hat sich durchgesetzt (Entwickler dokumentiert, welche Regeln er verletzt bzw. nicht beachtet)
- zwei Formen der "Deviation Procedure":
- Project Deviation: zu Beginn des Projekts einigt man sich auf die zu nutzenden Regeln(Regelsatz) bzw. die zu ignorierenden Regeln (Ausnahmesatz)
- Specific Deviation: spontaner Entscheid von Regeln und Ausnahmen
- Dokumentation des Entwicklers wichtig
B�cher
- Les Hatton; Safer C; Developing Software in High-Integrity and Safety-Critical Systems [McGraw]-Hill 1995; ISBN 0-070-707640-0
Unknown macro: {isbn}
- Caspers Jones; Applied Software Measurement; Assuring Productivity and Quality; [McGraw]-Hill 1996; ISBN 0-07-032826-9
Unknown macro: {isbn}
- Andrew K"nig; C Traps and Pitfalls; Addison-Wesley 1989; ISBN 0-20-1179288
Unknown macro: {isbn}
Website
http://www.misra.org.uk
E-Mail
Kommentar hinzufügen