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
:
Verschoben durch User
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.
Achso, manche Versionsverwaltung kann auch noch vor dem einchecken prüfen.
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.
:
Bearbeitet durch User
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
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).
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
1 | 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.
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.
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
1 | if( c >= '0' && c <= '9' ) |
2 | ...
|
bzw.
1 | if( isdigit( c ) ) |
2 | ...
|
wohingegen diese beiden Versionen für (Gross-) Buchstaben
1 | if( c >= 'A' && c <= 'Z' ) |
2 | ...
|
und
1 | if( isupper(c) ) |
2 | ...
|
eben NICHT gleichwertig sind. Die zweite Version ist in Ordnung, die erste Version hat unspezifiziertes Verhalten.
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.
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. :-)
:
Bearbeitet durch User
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
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.
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 ...
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
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.
:
Bearbeitet durch User
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?
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.
:
Bearbeitet durch User
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.
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 :)
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:
1 | struct tnode * pt; /* tnode is incomplete at this point */ |
2 | struct tnode |
3 | {
|
4 | int count; |
5 | struct tnode *left; |
6 | struct tnode * right; |
7 | }; /* 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
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.
1 | struct xyz; |
2 | |
3 | void foo( struct xyz* ptr ) |
4 | {
|
5 | bar( ptr ); |
6 | }
|
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.
1 | struct parent |
2 | {
|
3 | struct child * child_; |
4 | };
|
5 | |
6 | struct child |
7 | {
|
8 | struct parent * parent_; |
9 | };
|
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.
1 | struct child; |
2 | |
3 | struct parent |
4 | {
|
5 | struct child * child_; |
6 | };
|
7 | |
8 | struct child |
9 | {
|
10 | struct parent * parent_; |
11 | };
|
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.
:
Bearbeitet durch User
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.
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
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 :-)
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
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.
:
Bearbeitet durch User
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.
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).
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.
:
Bearbeitet durch User
Karl Heinz schrieb: > Merkt man, dass ich Misra nicht mag? Da braucht es nicht viel für, also nicht viel MISRA.
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
Hier ist der entsprechende Abschnitt aus Regel 18.1:
1 | A complete declaration of the structure or union shall |
2 | be included within any translation unit that reads from |
3 | or writes to that structure. A pointer to an incomplete |
4 | type is itself complete and is permitted, and therefore |
5 | 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[]")
:
Bearbeitet durch User
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
1 | MISRA wurde von der Automotive-Industrie in der Rueckschau entworfen, als |
2 | klar wurde, dass mit der Sprache C nicht mal "eben so" programmiert werden |
3 | konnte, weil selbst informatisch ausgebildete Nicht-C-Programmierer (und |
4 | die am Beginn weit verbreiteten umgeschulten Elektrotechnik und |
5 | Maschinenbau-Ingenieure sowieso) ueber die Unzulaenglichkeiten der Sprache |
6 | stolpern. Polemisch gesagt, aus Nicht-C-Programmierern werden miserable |
7 | C-Programmierer, daher der Name. |
8 | Warum sich gerade die (deutsche) Automobilindustrie so bereitwillig in die |
9 | Geiselhaft der Sprache C begeben hat, ist mir noch heute schleierhaft, denn |
10 | die Tools (Compiler) fuer den Loewenanteil der Steuergeraete waren noch bis |
11 | weit nach 2000 vollkommen hahnebuechen, teilweise sogar von C89 abweichend |
12 | (erinnert sich noch jemand an den Cosmic-Praeprozessor?) und bei der |
13 | Handvoll an automotive-grade CPUs haette die Finanzierung z.B. einer |
14 | Modula-2 Toolchain im Nachhinein gigantische Kosten gespart. |
15 | So stehen wir nun noch immer mit C da, C89 ist durch Autosar fuer weitere |
16 | Jahre als Standard einzementiert, es gibt Heerscharen an Beinahe- |
17 | Programmierern, die zwar MISRA befolgen, aber die zugrunde liegenden |
18 | Probleme (wie C die abstrakte Maschine auf ihre reale Plattform abbildet) |
19 | nicht annaehernd verstehen, und ein Haufen Manager, die sich mangels |
20 | Fachkenntnis an leicht zu merkenden Begriffen wie MISRA und Autosar |
21 | festhalten. |
22 | |
23 | Fazit: fuer jemanden der C beherrschen will, sollte die Religion |
24 | "LINT" und nicht MISRA sein. |
dem ist aus meiner Sicht nur wenig hinzuzufügen.
:
Bearbeitet durch User
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??
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.
>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?
> 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.
:
Bearbeitet durch User
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.