MISRA

hi,

verwendet hier jemand in nem Projekt eine MISRA Überprüfung? Welches Programm nehmt ihr dafür? Ist MISRA sinnvoll, was meint ihr?

lg

gerald1 schrieb:

verwendet hier jemand in nem Projekt eine MISRA Überprüfung?

nein, ich nicht. das mag jetzt vielleicht überheblich klingen, aber ich traue mir zu, nicht solchen mist zu coden, so dass ich misra-regeln beachten müsste.

Ich höre von MISRA gerade das erste mal.

<a href= schrieb:

http://www.embedded.com/columns/beginerscorner/9900659?_requestid=427335">Rule 49 (advisory): Tests of a value against zero should be made explicit, unless the operand is effectively Boolean.

Wir wollten schon immer ein wenig öfter NULL sagen.

Rule 104 (required): Non-constant pointers to functions shall not be used.

Warum nicht?

Aber MISRA wäre was für's Forum!
Beschwert sich von selbst wenn man malloc castet...

pointercrash**

'mngbd schrieb:

Aber MISRA wäre was für's Forum!

Länger her, aber hatten wir schon. Mit Regel 104 gibt's meine Systick- Slots, die kooperative Eventqueue und meinen präemptiven Hardware- Handler nicht mehr.
Eine andere Regel zerlegt mir mein System, wo ich Hardwarezugriffe code usw., das Ding ist in der Summe das totale Ärgernis, obwohl das eine oder andere durchaus Sinn machen würde. Bei mir bleibt der MISRA- Checker aus und ich lasse mir das nach dem ersten Versuch damit nie wieder drüberbraten.

pointercrash() schrieb:

'mngbd schrieb:

Aber MISRA wäre was für's Forum!

Länger her, aber hatten wir schon. Mit Regel 104 gibt's meine Systick- Slots, die kooperative Eventqueue und meinen präemptiven Hardware- Handler nicht mehr.

Du würdest es halt anders implementieren. Ob das dann sicherer ist oder nicht steht auf einem anderen Blatt

zu misra-regeln werden doch immer die armen elektronikkomponenten-zulieferer der autoindustrie verdonnert. und was hat's geholfen? nix. pleite sind sie trotzdem.

Hallo

Bestechende Logik...

chrische

chrische5 schrieb:

Bestechende Logik.

oh, bist du davon betroffen? war nicht böse gemeint.

Hallo

Nein eher nicht, aber der Zusammenhang wirkt wie von Homer erkannt...

chrische

chrische5 schrieb:

Nein eher nicht, aber der Zusammenhang wirkt wie von Homer erkannt...

homer simpson, oder dieser antike poet? egal, mit logik haben's hier doch viele nicht so. wundert mich, dass dir sowas überhaupt auffällt, zumal du hättest erkennen können, dass ich hemmungslos übertreibe. wie so oft.

Hallo

Homer Simpson und der Stein...

chrische

pointercrash**

Tim schrieb:

pointercrash() schrieb:

'mngbd schrieb:

Aber MISRA wäre was für's Forum!

Länger her, aber hatten wir schon. Mit Regel 104 gibt's meine Systick- Slots, die kooperative Eventqueue und meinen präemptiven Hardware- Handler nicht mehr.

Du würdest es halt anders implementieren. Ob das dann sicherer ist oder nicht steht auf einem anderen Blatt

Auf jeden Fall sähe es viel häßlicher aus.
Ich stopfe Funktionspointer in irgendwann auszuwertende Listen, um mal den Grundmechanismus anzudeuten. Klar brauche ich dazu non- constant function pointer. Alternativ müßte ich Tokens parsen oder sowas und das bedeutet viel Geschreibsel, um zwangsweise obfuscation im Dienste der Codesicherheit zu betreiben - das ist doch Schwachmatenkram. :p
Viele Sachen sehe ich ja ein, aber sowas ist ein "killing joke", an dem Zeug ist aber meines Wissens nichts geändert worden, wird mal wieder Zeit, ein paar Vollnullpen zum Badeurlaub zu schicken, um einen Vormittag über "Bing" und "Bong" zu diskutieren. Wird schon was Kluges dabei rauskommen.

abc.w

Habe gerade diesen Thread gesehen

gerald1 schrieb:

Welches Programm nehmt ihr dafür?

Ein Tool von PRQA, weiss nicht, in welcher Version.

gerald1 schrieb:

Ist MISRA sinnvoll, was meint ihr?

Ja.

abc.w schrieb:

gerald1 schrieb:

Ist MISRA sinnvoll, was meint ihr?

Ja.

begründung?

volkard

gerald1 schrieb:

Ist MISRA sinnvoll, was meint ihr?

Für C mag es sinnvoll sein. Aber nicht für mehr Sprachen und auch für C nur eingeschränkt. Manche Regeln sind auch Unfug.

volkard schrieb:

Aber statt MISRA zu benutzen, ist es unter Umständen besser, nach C++ aufzusteigen und MISRA dort nicht zu benutzen.

c++ fehlerquellen werden von MISRA-C doch garnicht abgedeckt. wenn mich nicht alles täuscht, gibt es übrigens auch misra-regeln für c++. das sind bestimmt viele-viele mehr.
btw, c++ und aufsteigen ist ein widerspruch.

Mmacher

Bevor irgendwas falsches über MISRA geschrieben wird:

MISRA ist letztendlich eine Ansammlung von Programmierer-Regeln.
Für jemanden der noch nie mit MISRA zu tun hatte, ist das erstmal eine hohe Hürde.
Unter anderem verbietet MISRA einen frei berechenbaren Pointer zu verwenden.

Meistens kommt MISRA in der Automobil-, Luftfahrt- und in der Medizintechnik zur Anwendung.

Salopp ausgedrückt, soll MISRA dafür sorgen, daß die Anforderungen von Auftraggeber und die Interpretation durch Programmierer (oder Software-Firma, ... ) eine einheitliche Grundlage haben, eben dieses MISRA.
Diese Grundlage hat ein vorrangiges Ziel: Soliden Code zu erzeugen. Und dadurch (normalerweise) zuverlässigere Produkte.

Des weiteren ist es nicht unbedingt notwendig alle MISRA-Regeln einzuhalten. Denn der Auftraggeber und Programmierer können in ihrem Pflichtenheft vereinbaren, daß einige bestimmte MISRA-Regeln außer acht gelassen werden kann.

Und: MISRA ist nicht an eine bestimmte Programmiersprache wie C, C++ oder Delphi (Pascal) gebunden!

Martin

P.S.: Zum Vergleich: Wir wissen (hoffentlich) alle, warum es die VDE-Normen gibt? Eine Firma die elektrische Produkte in Deutschland inverkehrbringt, muß die geltenden VDE-Normen beachten, welche auf ihr Produkt zutreffen. Ohne diese Normen wären wir Normalverbraucher im Alltag von massig Schrott oder lebensgefährlichen Gegenständen umgeben.

Mmacher: gut erklärt *daumen_hoch*
aber gibts wirklich auch misra-regeln für pascal?

volkard

Mmacher schrieb:

Salopp ausgedrückt, soll MISRA dafür sorgen, daß die Anforderungen von Auftraggeber und die Interpretation durch Programmierer (oder Software-Firma, ... ) eine einheitliche Grundlage haben, eben dieses MISRA.
Diese Grundlage hat ein vorrangiges Ziel: Soliden Code zu erzeugen. Und dadurch (normalerweise) zuverlässigere Produkte.

Ja, die Ziele sind hoch.

Des weiteren ist es nicht unbedingt notwendig alle MISRA-Regeln einzuhalten. Denn der Auftraggeber und Programmierer können in ihrem Pflichtenheft vereinbaren, daß einige bestimmte MISRA-Regeln außer acht gelassen werden kann.

Ich kann mir nicht vorstellen, daß die richtigen ausgelassen werden.

Und: MISRA ist nicht an eine bestimmte Programmiersprache wie C, C++ oder Delphi (Pascal) gebunden!

Nee, dazu gibt es ja Sachen wie MISRA-C.
continue und break sollen nicht benutzt werden.
der wert einer void-funktion darf nicht benutzt werden.
single exit.
NULL darf nicht dereferenziert werden.

P.S.: Zum Vergleich: Wir wissen (hoffentlich) alle, warum es die VDE-Normen gibt? Eine Firma die elektrische Produkte in Deutschland inverkehrbringt, muß die geltenden VDE-Normen beachten, welche auf ihr Produkt zutreffen. Ohne diese Normen wären wir Normalverbraucher im Alltag von massig Schrott oder lebensgefährlichen Gegenständen umgeben.

Schlechter Vergleich.

volkard schrieb:

der wert einer void-funktion darf nicht benutzt werden.

das geht sowieso nicht.