Misra C Programmierrichtlinien

[Heinz (Gast)]

Hallo!

Würde mich gerne mal mit den Programmierrichtlinien von MISRA C 
auseinandersetzen, finde aber im Internet nicht die Informationen, die 
ich brauche. Meine Fragen dazu:

WO bekomme ich das aktuelle Dokument zu MISRA C (ist das nur 
kostenpflichtig erhältlich)?

Wie wird beim Programmieren von µCs (z.B. mit ATmelStudio) die 
Einhaltung dieser Regeln überprüft?

LG Heinz

[kläb (Gast)]

Heinz schrieb:
> Wie wird beim Programmieren von µCs (z.B. mit ATmelStudio) die
> Einhaltung dieser Regeln überprüft?

Kann man bei manchen Kompilern schon einstellen.
Ansonsten gibt es auch statische Code Analyse Tools.
Mir fällt da spontan PCLint ein.

[kläb (Gast)]

Achso, manche Versionsverwaltung kann auch noch vor dem einchecken 
prüfen.

[Christian G. (christiang)]

Naja, dann such doch mal nach z.B. +Misra +c +pdf mit der Suchmaschine 
deiner Wahl, da kommt schon einiges zusammen.
Es sind zwar nicht die originale, aber viel mehr steht in denen auch 
nicht drin.
Nachtrag: Oder aber du investierst halt die etwa 15€ für das Original.

[Heinz (Gast)]

Danke für eure Antworten!

Ich habe nun den Misra C Standard von 2004 erhalten/gefunden und gehe 
die einzelnen Regeln durch. Dabei verstehe ich 2 Punkte nicht:

Regel 1.1
All code shall conform to ISO/IEC 9899:1990
“Programming languages — C”, amended and corrected by
ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996

Muss ich mir da nun eine eigene Norm zulegen, welche die Regel 1.1 
beschreibt?

Regel 1.2
No reliance shall be placed on undefined or unspecified
behaviour.

Bedeutet das, dass ich undefiniertes/ungewolltes Verhalten der Software 
beim Testen nicht vernachlässigen darf (z.B. wenn ein Fehler einmal bei 
einem Test auftritt) und dass ich diesem Fehler nachgehen soll, obwohl 
er bei folgenden Tests nicht mehr auftritt? Oder bezieht sich dieser 
Punkt nur auf Fehlermeldungen der Entwicklungsumgebung?

THX Heinz

[Luther B. (luther-blissett)]

Heinz schrieb:

> Regel 1.2
> No reliance shall be placed on undefined or unspecified
> behaviour.
>
> Bedeutet das, dass ich undefiniertes/ungewolltes Verhalten der Software
> beim Testen nicht vernachlässigen darf (z.B. wenn ein Fehler einmal bei
> einem Test auftritt) und dass ich diesem Fehler nachgehen soll, obwohl
> er bei folgenden Tests nicht mehr auftritt? Oder bezieht sich dieser
> Punkt nur auf Fehlermeldungen der Entwicklungsumgebung?

"undefined" und "unspecified" bezieht sich auf die Sprache C. Schau mal 
hier, Annex J:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

Z.B. ist die Reihenfolge in der Funktionsargumente berechnet werden 
unspezifiziert, integer Überläufe sind dagegen undefiniert (was rasend 
gefährlich ist).

[Karl H. (kbuchegg)]

Heinz schrieb:
> Danke für eure Antworten!
>
> Ich habe nun den Misra C Standard von 2004 erhalten/gefunden und gehe
> die einzelnen Regeln durch. Dabei verstehe ich 2 Punkte nicht:
>
> Regel 1.1
> All code shall conform to ISO/IEC 9899:1990
> “Programming languages — C”, amended and corrected by
> ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and
> ISO/IEC 9899/COR2:1996
>
> Muss ich mir da nun eine eigene Norm zulegen, welche die Regel 1.1
> beschreibt?

Das ist der 1990-er Standard von C, kurz als C90 bezeichnet.
Wenn du zb einen Kernighan&Ritchie in der Version für ANSI C hast, UND 
den auch einigermassen im Detail verstehst, dann programmierst du 
automatisch nach diesem Standard.
Ansonsten: ja, für Detailfragen ist dann das entsprechende Dokument 
zuständig. Wobei das den wenigsten etwas helfen wird. Denn in diesem 
Dokument muss man sich erst mal zurecht finden, damit man findet was man 
sucht. Die Standard Sprachbeschreibung ist hauptsächlich für 
Compilerbauer interessant, wenn es darum geht kleine Details abzuklären, 
wie das Verhalten exakt sein soll.

> Regel 1.2
> No reliance shall be placed on undefined or unspecified
> behaviour.
>
> Bedeutet das, dass ich undefiniertes/ungewolltes Verhalten der Software
> beim Testen

Äh. nein.
Dann ist es schon zu spät.

Es heißt vor allen Dingen, dass du C gut genug kennen musst, um zu 
wissen wann es zu undefiniertem bzw. unspezifiziertem Verhalten kommt.

Ein Beispiel.
Es bedeutet, dass du zb nicht

  j = value1[i++] + value2[i++];

schreiben darfst, selbst wenn auf DEINEM System genau das richtige raus 
kommt. Die Reihenfolge, wann genau die Inkrement-Operationen gemacht 
werden, ist nun mal nicht definiert. Das einzige was definiert ist, ist 
das die Operation vor dem nächsten Sequence-Point ausgeführt wird. Aber 
nicht wann genau. Damit ist aber nicht sicher gestellt, welchen Wert i 
bei jedem der beiden Inkrement-Operationen hat.

MISRA kann dir fehlendes Wissen nicht ersetzen. Selbst wenn es sich zur 
Aufgabe gesetzt hat, die Sprache soweit zu kastrieren, dass auch 
schwächere Programmierer damit klar kommen.

[Steel (Gast)]

Nein, das bedeutet, dass du dich nicht auf Dinge verlassen sollst die 
zufällig funktionieren obwohl das Verhalten gemäß Standard nicht 
spezifizier t ist. Beispielsweise darf man bei einer Union nur über über 
den Weg auslesen, auf dem man reingeschrieben hat. Auch wenn es gerne 
mal anders gehandhabt wird und mit (fast?) allen Compilern funktioniert.

[Karl H. (kbuchegg)]

Ein anderes, subtileres Beispiel für unspezifiziertes Verhalten ist zb 
das hier.

Zum Thema Zeichensatz.
Der C Standard definiert, dass es die Zeichen '0' bis '9' und die 
Zeichen 'A' bis 'Z' (unter anderem geben muss). D.h. du kannst dich bei 
Textausgaben darauf verlassen, dass eine Ausgabe eines 'A' auch 
tatsächlich zu einem 'A' an der Konsole führt (wobei das streng genommen 
auch nicht der Fall ist, denn der Standard schreibt auch nicht vor dass 
es eine Konsole geben muss)

Die Subtilität besteht darin, dass die der C-Standard die Garantie gibt, 
dass die Zeichen '0' bis '9' durchgehend im Zeichensatz und 
hintereinander angeordnet sind. Dasselbe gilt aber nicht für die 
Buchstaben 'A' bis 'Z'.

D.h. laut C Standard sind die beiden Versionen eines Codestücks, welches 
prüfen soll, ob ein bestimmtes Zeichen c ein Ziffern-Zeichen (und nur 
ein Ziffernzeichen) ist, identisch und gleichwertig

  if( c >= '0' && c <= '9' )
    ...

bzw.

  if( isdigit( c ) )
    ...

wohingegen diese beiden Versionen für (Gross-) Buchstaben

  if( c >= 'A' && c <= 'Z' )
    ...

und

  if( isupper(c) )
    ...

eben NICHT gleichwertig sind. Die zweite Version ist in Ordnung, die 
erste Version hat unspezifiziertes Verhalten.

[Luther B. (luther-blissett)]

Karl Heinz schrieb:

> eben NICHT gleichwertig sind. Die zweite Version ist in Ordnung, die
> erste Version hat unspezifiziertes Verhalten.

bzw. implementation-defined,da es 'A' und 'Z' sowohl im basic source wie 
im basic execution character set geben muss. 5.2.1 sagt dann:

"In a character constant or string literal, members of the execution 
character set shall be represented by corresponding members of the 
source character set"

und

"The values of the members of the execution character set are 
implementation-defined."

Das musste leider wegen EBCDIC rein - da haben die Buchstaben 'A'-'Z' 
die Codes 0xc1-0xc9,0xd1-0xd9,0xe2-0xe9. In den Lücken sind dann z.B. 
irgendwelche Sonderzeichen.

[Karl H. (kbuchegg)]

Luther Blissett schrieb:

>> eben NICHT gleichwertig sind. Die zweite Version ist in Ordnung, die
>> erste Version hat unspezifiziertes Verhalten.
>
> bzw. implementation-defined

da hau ich immer gerne mal daneben, was denn jetzt 'undefined' bzw. 
'unspecified' bedeutet.
Ich weiss dass das eine verlangt, dass zwar irgendwas sinnvolles 
passiert (was auch dokumentiert werden muss) und zwar immer das gleiche, 
während bei dem anderen alle Optionen offen sind (inklusive Festplatte 
formatieren und abstürzen). Aber ich kann mir nie merken, welcher der 
beiden Ausdrücke jetzt was ist. :-)

[Fred (Gast)]

Karl Heinz schrieb:
> da hau ich immer gerne mal daneben, was denn jetzt 'undefined' bzw.
> 'unspecified' bedeutet.
> Ich weiss dass das eine verlangt, dass zwar irgendwas sinnvolles
> passiert (was auch dokumentiert werden muss) und zwar immer das gleiche,
> während bei dem anderen alle Optionen offen sind (inklusive Festplatte
> formatieren und abstürzen). Aber ich kann mir nie merken, welcher der
> beiden Ausdrücke jetzt was ist. :-)

undefined: startet potentiell den Dritten Weltkrieg

implementation-defined: es gibt mehrere Möglichkeiten, die 
Implementierung muß dokumentieren, welche sie wählt

unspecified: es gibt mehrere Möglichkeiten, die Implementierung muß 
nichts dokumentieren

[Karl H. (kbuchegg)]

Fred schrieb:

> undefined: startet potentiell den Dritten Weltkrieg
>
> implementation-defined: es gibt mehrere Möglichkeiten, die
> Implementierung muß dokumentieren, welche sie wählt
>
> unspecified: es gibt mehrere Möglichkeiten, die Implementierung muß
> nichts dokumentieren

Danke.
Jetzt brauch ich nur noch entsprechende Eselsbrücken :-)


Ich denke aber, dass im bisherigen Verlauf ganz gut rausgekommen ist, 
dass MISRA eben nicht so etwas wie ein Subset von C ist, so dass man 
nicht den vollen Sprachumfang lernen muss und trotzdem 'sichere' 
Programme schreiben kann. Ich seh MISRA eher als das Gegenteil an: Man 
muss C bereits beherrschen um zu verstehen, wie und wo einem ein 
gewisser, durch MISRA geforderter, Verzicht die Codequalität erhöhen 
kann. Denn eines ist MISRA ganz sicher nicht: ein hinten nach 
eingezogenes Sicherheitsnetz, mit der Zusicherung keine Fehler mehr 
machen zu können. Leider wird MISRA gerne schon mal als dieses 
angesehen.

[Jörg W. (dl8dtl) (Moderator)]

Karl Heinz schrieb:
> Aber ich kann mir nie merken, welcher der beiden Ausdrücke jetzt was
> ist. :-)

Als typisches Beispiel für "undefined behaviour" nennt der Standard
in einer Fußnote signed integer overflow.

Hatten wir ja neulich hier gerade, als eine aktuelle GCC-Version
irgendwas wegoptimiert hat in der Annahme, dass signed integer ja nicht
überlaufen darf ...

[Heinz (Gast)]

Hallo, danke für Eure Infos...

Eine Frage hätte ich noch zu Regel 3.1:
All usage of implementation-defined behaviour shall be
documented.

This rule requires that any reliance on implementation-defined 
behaviour, which is not specifically
addressed by other rules, shall be documented, for example by reference 
to compiler documentation.
Where a specific behaviour is explicitly covered in another rule, only 
that specific rule needs to be
deviated if required. See ISO/IEC 9899:1990 Appendix G [2] for a 
complete list of these issues.

Was bedeutet diese Regel? Heißt das lediglich, dass programmierte 
Funkionalität kommentiert werden muss?

Danke, lG

[Karl H. (kbuchegg)]

Heinz schrieb:

> Was bedeutet diese Regel?

Welche Teile davon sind jetzt unklar?

> Heißt das lediglich, dass programmierte
> Funkionalität kommentiert werden muss?

Ich denke es liegt auf der Hand, was die Misra Regel in der Praxis 
bedeutet.

Wenn es Compiler spezifisches Verhalten gibt und dein Programm genau auf 
diesem Verhalten aufbaut, dann musst du das dokumentieren, dass das so 
ist und wie das von dir (bzw. deinem Programm) vorausgesetzte Verhalten 
sein muss.

Sobald du verstanden hast, was 'implementation-defined behaviour' 
bedeutet, ist das sehr naheliegend, was da gemeint ist. Tip: Mit 
'implementation' ist nicht dein Programm gemeint, sonder die 
Implementierung des Compilers. Der ist ja auch ein Programm und seine 
Programmierer mussten sich an manchen Stellen für eine von mehreren 
möglichen Varianten entscheiden. Nur: Für welche - und inwiefern hat das 
Auswirkungen auf das von dir geschriebene Programm?

> Heißt das lediglich, dass programmierte Funkionalität kommentiert werden muss?

Bist du sicher, dass du der richtige Mann für den Job bist?
Wer Richtlinien-Polizei spielen muss, sollte sich im Regelwerk (und 
damit ist das C-Regelwerk gemeint) erstklassig auskennen. Speziell dann, 
wenn er entscheiden muss, inwiefern das Misra Zusatz-Regelwerk da noch 
mit eingreift. Wer sich aber im C-Regelwerk erstklassig auskennt, für 
den ist 'implementation-defined' kein Fremdwort sondern täglich Brot.

[Heinz (Gast)]

Wenn man frisch von der Schulausbildung kommt und absolut keine 
Erfahrung hat, ist es doch verständlich, dass man solche Themen noch 
nicht wirklich beherrscht, oder?

[Karl H. (kbuchegg)]

Heinz schrieb:
> Wenn man frisch von der Schulausbildung kommt und absolut keine
> Erfahrung hat, ist es doch verständlich, dass man solche Themen noch
> nicht wirklich beherrscht, oder?

Aber zumindest ein wenig Englisch sollte man schon können. Das was in 
den Misra Regeln steht und das wonach du fragst, sind komplett andere 
Baustellen. Die Misra Regel spricht davon, dass du dokumentieren musst, 
wo dein Programm auf compiler spezifischen Verhalten aufbaut (und das du 
angeben musst, wo man das in der Compilerdoku nachlesen kann) - du 
sprichst davon dass du die Funktionsweise deines Programm kommentieren 
sollst.
Der halbe Thread beschäftigt sich damit, wie der Compiler bzw. dessen 
zulässige Sprachauslegung, ein von einem Programmierer geschriebenes 
Programm beeinflusst.

Zum anderen kommt man nicht frisch von der Schulausbildung und muss in 
einer Firma den Misra Beauftragten spielen.

[Jörg W. (dl8dtl) (Moderator)]

Heinz schrieb:
> Wenn man frisch von der Schulausbildung kommt und absolut keine
> Erfahrung hat, ist es doch verständlich, dass man solche Themen noch
> nicht wirklich beherrscht, oder?

Es ist dann aber nicht verständlich, warum man ausgerechnet diese
Aufgabe aufgehalst bekommt.  MISRA benutzt man für gewöhnlich dort, wo
es (im Extremfall) auf Leben und Tod ankommt; die ganze Geschichte
stammt schließlich aus dem Fahrzeugbau.  MISRA ist nicht dafür da,
fehlende Praxiserfahrung eines Programmierers zu ersetzen, sondern
dafür, dass man trotz gutem Verständnis für die Frage hin und wieder
auch mal eine Fratzenfalle übersehen kann.  Selbst, wenn man den
C-Standard gut kennt, rennt man nämlich hin und wieder in sowas rein.

Gegen fehlende Praxiserfahrung hilft eigentlich nur ein guter Mentor
und (gerade in der Anfangszeit) ausgiebige Code-Reviews.

[Heinz (Gast)]

Ja das ist schon klar...

Ich erstelle spezifische interne Programmierregeln und wollte ein paar 
Regeln aus dem MISRA ebenfalls berücksichtigen. Es ist nicht meine 
absicht, mit MISRA C zu lernen :)

[Heinz (Gast)]

Es gibt da noch eine Regel, die mir nicht ganz klar ist:
All structure and union types shall be complete at the end of a
translation unit.

Codebeispiel:

struct tnode * pt; /* tnode is incomplete at this point */
struct tnode
{
int count;
struct tnode *left;
struct tnode * right;
}; /* type tnode is now complete */

Kann mir jemand erklären, was das bedeutet? Ich weiß, was eine Struktur 
ist, aber mir ist nicht klar was mit dieser Regle gemeint ist!

Vielen Dank

[Karl H. (kbuchegg)]

incomplete bedeutet einfach nur, dass nichts näheres über den 
Strukturaufbau bekannt ist.
Das reicht zb um einen Pointer auf eine Struktur einzurichten. Es reicht 
aber nicht um eine Variable von diesem Datentyp einzurichten, oder 
besagten Pointer zu dereferenzieren.

struct xyz;

void foo( struct xyz* ptr )
{
  bar( ptr );
}

xyz wäre hier incomplete. Es ist zwar bekannt, dass es eine Struktur mit 
Namen xyz gibt (und damit ist dann struct xyz auch kein Tippfehler), 
mehr aber nicht. Um einen Pointer als Funktionsargument benutzen zu 
können, ist das genug.

Du kennst eine incomplete struct vielleicht unter dem Namen "forward 
declaration".

Wo braucht man sowas auf jeden Fall?
Zum Beispiel wenn man Strukturen hat, die jeweils Pointer auf den 
anderen enthalten sollen.

struct parent
{
  struct child * child_;
};

struct child
{
  struct parent * parent_;
};

das würde nicht compilieren. Denn ein struct child ist nicht bekannt, 
wenn die struct parent definiert wird.
So rum, mit einer forward declaration, geht das.

struct child;

struct parent
{
  struct child * child_;
};

struct child
{
  struct parent * parent_;
};

In dem Fall ist der Datentyp struct child dann eine "Zeit lang" 
incomplete. Von der forward declaration bis dann irgendwann tatsächlich 
mal die Struktur definiert wird.  Das passt auch, denn in der 
Zwischenzeit wird der incomplete Typ nur dazu benutzt einen Pointer zu 
definieren. Und dazu reicht es, wenn der Datentyp incomplete ist. Denn: 
wie groß ein Pointer ist, das weiß der Compiler sowieso. Es geht nur 
noch um die Fragestellung ob ein 'struct child' überhaupt existiert, 
oder ob das vielleicht ein Tippfehler ist.

[Heinz (Gast)]

Super, danke!

[Jörg W. (dl8dtl) (Moderator)]

Karl Heinz schrieb:
> Wo braucht man sowas auf jeden Fall?

Außerdem kann man damit ein “information hiding” betreiben, indem man
die so benannte Stuktur nur als Zeiger durchreicht: man hat irgendeine
Bibliotheksfunktion, die einen Zeiger auf eine solche Struktur liefert.
Den Inhalt selbst kennt man dabei nicht, man kann auf die Elemente
also nicht zugreifen.  Alles, was man damit tun kann ist, den Zeiger
an andere Bibliotheksfunktionen weiterzureichen.

Wenn ich diese Regel richtig deute, wollen sie genau so etwas nicht
haben.

Eigentlich dürften sie dann nicht einmal stdio zulassen, denn “FILE *”
ist ja letztlich nichts anderes als genau dieses Prinzip. ;-)  fopen()
liefert den Zeiger, der Inhalt ist intransparent für die Applikation.
Benutzt werden sie dann in putc(), getc() etc.

[Bülent C. (mirki)]

Karl Heinz schrieb:
> Es heißt vor allen Dingen, dass du C gut genug kennen musst, um zu
> wissen wann es zu undefiniertem bzw. unspezifiziertem Verhalten kommt.

Das Thema hatten wir ja schon ausführlich genug ausdiskuttiert :-) Nur 
mal so am Rande angemerkt

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:

> Eigentlich dürften sie dann nicht einmal stdio zulassen


http://www.ristancase.com/html/dac/manual/3.12.02%20MISRA-C%202004%20Rules.html

Schau dir mal Regel 20.9 an :-)

[Yalu X. (yalu) (Moderator)]

Jörg Wunsch schrieb:
> Eigentlich dürften sie dann nicht einmal stdio zulassen, denn “FILE *”
> ist ja letztlich nichts anderes als genau dieses Prinzip. ;-)

Zumindest in der GNU- und der AVR-Libc ist FILE complete, d.h. die
Elemente der FILE-Struktur sind für ein Anwendungsprogramm sichtbar. Die
MISRA-Richtlinie ist hier also (auch ohne die von Karl Heinz zitierte
Regel 20.9) erfüllt, obwohl es sicher nicht im Sinne von MISRA ist, wenn
von dieser Offenlegung der Struktur tatsächlich Gebrauch gemacht wird.

Hier kam die diese Frage ebenfalls auf, nur verstehe ich nicht ganz, was
der Mensch von der MISRA C Working Group mit seiner Antwort ausdrücken
möchte:

  http://www.misra.org.uk/forum/viewtopic.php?f=77&t=590

[Karl H. (kbuchegg)]

Yalu X. schrieb:

> Hier kam die diese Frage ebenfalls auf, nur verstehe ich nicht ganz, was
> der Mensch von der MISRA C Working Group mit seiner Antwort ausdrücken
> möchte:
>
>   http://www.misra.org.uk/forum/viewtopic.php?f=77&t=590

Interessante Antwort.
Passt irgendwie so gar nicht zur Regel.
Der Antworter sagt, dass es ok ist einen Pointer auf eine incomplete 
struct zu definieren, weil der Pointer selbst ja insofern complete ist.
Schön. Nur sagt die Regel etwas ganz anderes. Die sagt '*All* structure 
or ...'
Wenn diese Regel so interpretiert werden soll, wie der Antworter das 
implizieren möchte, dann frag ich mich, wozu die Regel überhaupt gut 
sein soll.
Denn wenn ich den Pointer dereferenziere UND der zugrunde liegende 
struct Typ an dieser Stelle incomplete ist, dann bringe ich das sowieso 
nicht durch den Compiler. Dazu brauch ich keine Misra Regel.

[Yalu X. (yalu) (Moderator)]

Karl Heinz schrieb:
> Denn wenn ich den Pointer dereferenziere UND der zugrunde liegende
> struct Typ an dieser Stelle incomplete ist, dann bringe ich das sowieso
> nicht durch den Compiler. Dazu brauch ich keine Misra Regel.

Eben, das hat mich auch etwas stutzig gemacht.

[Jörg W. (dl8dtl) (Moderator)]

Karl Heinz schrieb:
> Schau dir mal Regel 20.9 an :-)

Ist im Originaldokument wenigstens noch begründet:

. stdio hat denen zu viel undefined und implementation-defined behaviour
. sie gehen davon aus, dass man das in produktivem Code sowieso nicht 
bräuchte

Man darf von der Regel abweichen, aber “then the issues associated with
the feature [also dem, was man von stdio nutzen will] need to be
understood”.

Ich habe mir die 18.1 nochmal angesehen.  Heinz, wenn du dir den
kompletten Text durchliest, wird sonnenklar, dass die Regel nur
dafür da ist, dass man nicht „wild“ auf die Strukturelemente zugreifen
soll (indem man sich irgendwie seine eigene Idee der Struktur drüber
legt, die nicht notwendig mit dem Original übereinstimmt und daher
zu undefined behaviour führt).  Opaque pointers sind jedoch
ausdrücklich in der Regel gestattet (Begründung: ein Zeiger auf einen
unvollständigen Typ ist selbst ein vollständiger Typ und damit
statthaft).

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:

> Man darf von der Regel abweichen, aber “then the issues associated with
> the feature [also dem, was man von stdio nutzen will] need to be
> understood”.

In dem Moment, in dem ich das jetzt gelesen habe, ist mir ein Schmunzeln 
über das Gesicht gehuscht.
Ein paar der Misra Regeln sehe ich schon als sinnvoll an. Die Sache mit 
den nested Kommentaren und dann noch ein paar andere.
Aber da sind auch viele dabei, die es nur deswegen gibt, weil ein 
anscheinend nicht unerheblicher Teil der Programmierer eben NICHT C und 
typische Problemkreise sowie deren Lösung gut genug "understand", so 
dass man die Sprache verkrüppeln muss, um ihnen das Gefühl eines 
Sicherheitsnetztes zu geben.

Merkt man, dass ich Misra nicht mag?

> Ich habe mir die 18.1 nochmal angesehen.  Heinz, wenn du dir den
> kompletten Text durchliest, wird sonnenklar, dass die Regel nur
> dafür da ist, dass man nicht „wild“ auf die Strukturelemente zugreifen
> soll (indem man sich irgendwie seine eigene Idee der Struktur drüber
> legt, die nicht notwendig mit dem Original übereinstimmt und daher
> zu undefined behaviour führt).

Ehrlich:
Wer sowas macht, der gehört mit dem nassen Fetzen geschlagen und aus der 
Stadt gejagt.

Einmal hab ich sowas ähnliches gesehen. Da hat eine 
Nachwuchsprogrammiererin einen Struktur-Rückgabewert einfach in einen 
anderen Strukturtyp gecastet. Natürlich hat sie das nicht gesagt, 
sondern das Programm stürzte ab und nach einer ausgibigeren Debug 
Session, die über die Analyse des Stack Inhalts und warum der auf einmal 
nicht mehr stimmt, fand ich dann die Stelle und warum der return in den 
Wald führte.
Auf die Frage, warum sie das gemacht hat, kam die Antwort: weil der 
Compiler meinte, dass ihm da ein Cast fehlte weil die Typen nicht passen 
würden.
Wir haben uns dann darauf geeinigt, dass sie ihr Praktikum im nächsten 
Jahr nochmal neu anfangen würde.

[Bernd M. (bernd_m)]

Karl Heinz schrieb:
> Merkt man, dass ich Misra nicht mag?

Da braucht es nicht viel für, also nicht viel MISRA.

[chris_ (Gast)]

Hier gibt es einen Artikel zu Misra-C auf heise:
http://www.heise.de/developer/artikel/MISRA-C-Quasi-Standard-nicht-nur-fuer-Automotive-2087349.html

[Luther B. (luther-blissett)]

Hier ist der entsprechende Abschnitt aus Regel 18.1:

A complete declaration of the structure or union shall 
be included within any translation unit that reads from 
or writes to that structure. A pointer to an incomplete 
type is itself complete and is permitted, and therefore 
the use of opaque pointers is permitted.

Hinweis: "incomplete type" sind alle Typen deren Größe der Compiler 
nicht kennt. Das gilt auch für array die ohne Größenangabe deklariert 
sind ("extern int foo[]")

[Karl H. (kbuchegg)]

chris_ schrieb:
> Hier gibt es einen Artikel zu Misra-C auf heise:
> 
http://www.heise.de/developer/artikel/MISRA-C-Quasi-Standard-nicht-nur-fuer-Automotive-2087349.html

Aus einem der Kommentare
Ned_Nederlander schreibt

MISRA wurde von der Automotive-Industrie in der Rueckschau entworfen, als
klar wurde, dass mit der Sprache C nicht mal "eben so" programmiert werden
konnte, weil selbst informatisch ausgebildete Nicht-C-Programmierer (und
die am Beginn weit verbreiteten umgeschulten Elektrotechnik und
Maschinenbau-Ingenieure sowieso) ueber die Unzulaenglichkeiten der Sprache
stolpern. Polemisch gesagt, aus Nicht-C-Programmierern werden miserable
C-Programmierer, daher der Name.
Warum sich gerade die (deutsche) Automobilindustrie so bereitwillig in die
Geiselhaft der Sprache C begeben hat, ist mir noch heute schleierhaft, denn
die Tools (Compiler) fuer den Loewenanteil der Steuergeraete waren noch bis
weit nach 2000 vollkommen hahnebuechen, teilweise sogar von C89 abweichend
(erinnert sich noch jemand an den Cosmic-Praeprozessor?) und bei der
Handvoll an automotive-grade CPUs haette die Finanzierung z.B. einer
Modula-2 Toolchain im Nachhinein gigantische Kosten gespart.
So stehen wir nun noch immer mit C da, C89 ist durch Autosar fuer weitere
Jahre als Standard einzementiert, es gibt Heerscharen an Beinahe-
Programmierern, die zwar MISRA befolgen, aber die zugrunde liegenden
Probleme (wie C die abstrakte Maschine auf ihre reale Plattform abbildet)
nicht annaehernd verstehen, und ein Haufen Manager, die sich mangels
Fachkenntnis an leicht zu merkenden Begriffen wie MISRA und Autosar
festhalten.

Fazit: fuer jemanden der C beherrschen will, sollte die Religion
"LINT" und nicht MISRA sein.

dem ist aus meiner Sicht nur wenig hinzuzufügen.

[MarcVonWindscooting (Gast)]

Eure Kommentare sind Balsam auf meine Seele!
Als der Thread noch neu war, hab ich mal geschaut, was MISRA ist und ich 
war so entsetzt von dieser R"uckst"andigkeit, dass ich beschloss nichts 
zu schreiben, sonst heisst es noch ich sei gegen alles.
F"ur mich war das Verbot der //-Kommentare und das daraus entstehende 
Problem mit den /* */-Kommentaren (die dann ja als Ersatz dienen 
m"ussen) der Moment, an dem ich beschloss MISRA unter der Rubrik 
Schwachsinn einzuordnen.

Allerdings hat sich bei mir nun ein Unbehagen eingestellt: die 
Gewissheit zu haben, dass Automobil-Software von Leuten geschrieben 
werden muss, die sich diesem K"ase unterordnen ohne sich binnen 10Tagen 
das Leben zu nehmen.

Bekommt man eigentlich eine Lobotomie von der Kasse gezahlt, wenn man 
gezwungen ist in der Automobilbranche zu arbeiten??

[Rolf Magnus (Gast)]

Heinz schrieb:
> Regel 1.1
> All code shall conform to ISO/IEC 9899:1990
> “Programming languages — C”, amended and corrected by
> ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and
> ISO/IEC 9899/COR2:1996
>
> Muss ich mir da nun eine eigene Norm zulegen, welche die Regel 1.1
> beschreibt?

Eigentlich ja, wenn du es denn kannst ...

Karl Heinz schrieb:
> So stehen wir nun noch immer mit C da, C89 ist durch Autosar fuer
> weitere Jahre als Standard einzementiert,

Das ist mir auch schon aufgefallen, daß sich auch Autosar auf C89 
beruft.
Wie bei MISRA ist das ein logischer Fehler in der Spezifikation, denn 
C89 gibt es gar nicht mehr. Das Dokument wird in C99 offiziel für 
ungültig erklärt und ist bei den enstsprechenden Normungsgremien auch 
gar nicht mehr erhältlich. Wer sich also an die MISRA- bzw. 
Autosar-Regeln halten will, muß halt noch von früher eine Kopie von C89 
irgendwo rumliegen haben.

[chris_ (Gast)]

>Warum sich gerade die (deutsche) Automobilindustrie so bereitwillig in die
>Geiselhaft der Sprache C begeben hat, ist mir noch heute schleierhaft, denn
>die Tools (Compiler) fuer den Loewenanteil der Steuergeraete waren noch bis
>weit nach 2000 vollkommen hahnebuechen, teilweise sogar von C89 abweichend
>(erinnert sich noch jemand an den Cosmic-Praeprozessor?) und bei der
>Handvoll an automotive-grade CPUs haette die Finanzierung z.B. einer
>Modula-2 Toolchain im Nachhinein gigantische Kosten gespart.

Gibt es eine Modula-2 Toolchain für den Attiny13?

[Klaus W. (mfgkw)]

> Bekommt man eigentlich eine Lobotomie von der Kasse gezahlt, wenn man
> gezwungen ist in der Automobilbranche zu arbeiten??

Es gibt gottlob auch in dieser Branche etwas fortschrittlichere Ecken, 
wo sich niemand um MIS(T)RA kümmert.

[Jörg W. (dl8dtl) (Moderator)]

Rolf Magnus schrieb:
> Wie bei MISRA ist das ein logischer Fehler in der Spezifikation

Von MISRA gibt es meines Wissens jedoch bereits einen Update, der auf
C99 aufbaut.

[Klaus W. (mfgkw)]

Aber wer sollte das verwenden?

Wer bisher so kleingärtnerisch ist, daß er das bisherige MISRA nimmt, 
schafft in 20 Jahren keinen Umstieg.

Wer dagegen etwas flexibler in der Birne ist, nimmt eh kein MISRA.

-> ich gehe jede Wette ein, daß mir jegliches Update lange nicht in 
freier Wildbahn begegnet.