Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

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:
  1. sehr teuer (mehrere tausend Euro)
  2. 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

  • No labels