Benutzt von euch jemand in eurer Firma Coverty oder vergleichbare SW zur Fehleranylse des Quellcodes?
-
Falls ja, was genau benutzt ihr dafür und wie sind eure Erfahrungen zu solcher Software?
-
Wir benutzen pcLint und QA-C bzw QA-C++ bei uns. Wobei wir als Entwickler hauptsächlich pcLint einsetzen weil wir hier das Kommandozeilen Interface dabei haben.
Wenn man die Tools an die eigenen Compiler und an die eigene Projektumgebung angepasst hat, helfen Sie schon Fehler zu finden. Außerdem sorgen Sie bei uns dafür, dass der MISRA Standard eingehalten wird.
Alles in allem kann man sagen, Sie helfen Fehler zu finden.
Gruß
Tobi
-
Falls ja, was genau benutzt ihr dafür und wie sind eure Erfahrungen zu solcher Software?
Ich habe mal die Analyse Option vom Visual Studio Compiler benutzt. Hat ein paar Ungereimtheiten entdeckt. Ist schön wenn man so was hat, aber Tools ala Valgrind/Application Verifier finde ich da besser.
MISRA Standard
Mir erschliesst sich nicht so den Sinn hinter MISRA.
Dies mag aber auch mit den Eigenschaften meiner IDE zusammenhängen. Der Compiler hat da schon so einige bitterböse Macken, und die Standard C Libs sind alle nicht MISRA konform.
Einen schlechten Programmierstil wird auch MISRA nicht verhindern.
-
Bitte ein Bit schrieb:
... Mir erschliesst sich nicht so den Sinn hinter MISRA.
Dies mag aber auch mit den Eigenschaften meiner IDE zusammenhängen. Der Compiler hat da schon so einige bitterböse Macken, und die Standard C Libs sind alle nicht MISRA konform.
Einen schlechten Programmierstil wird auch MISRA nicht verhindern.
Nunja, in der Automobilzulieferer Industrie ist MISRA nun einmal gesetzt. Dieser Standard muss eingehalten werden, das wird meist vertraglich zugesichert. Tools zur statischen Codeanalyse helfen den Standard durchzusetzen.
Ansonsten ist es bei MISRA wie mit allen Coding(style) Standards. Die einen sagen es hilft, die anderen sagen es hilft nicht...
Auch kann man beispielsweise Hinweise auf böse casts bekommen. Ein Fall bei uns war (Zielsystem mit 24 kb Ram und 384 kb Flash) zum Beispiel ein böser Cast von int32 auf enum. Wenn man den Compiler so einstellt, dass er den kleinsten Typ für enum nimmt, dann ist der Cast oben kritisch weil da mist rauskommt wenn man es so macht wie bei uns.
Der Code ist irgendwo tief im System und wird nur in speziellen Fällen aufgerufen. Auf der unit test Umgebung "passt" es, da der enum dort 32 bit lang ist...
Dank pcLint haben wir den Fehler gefunden...
Gruß
Tobi
-
Das dürfte ja nur mit einem reinterpret_cast ein Problem sein. Wie kommt man denn überhaupt erst auf die Idee, so etwas zu verwenden?
Bzgl. statische Checker habe ich nur mal ganz kurz cppcheck ausprobiert. Da müsste ich mich mal wieder drum kümmern; denn ich gehe auch davon aus, dass sowas helfen kann, solange nicht zu viele false Positives kommen.
-
krümelkacker schrieb:
Das dürfte ja nur mit einem reinterpret_cast ein Problem sein. Wie kommt man denn überhaupt erst auf die Idee, so etwas zu verwenden?
...
Wenn du mir sagst wie ich in C anders casten soll, bzw. wenn ein externes (nicht in Source Code verfügbares) Interface mitspielt...
Nichtsdestotrotz, pflegt man die Tools, helfen Sie durchaus den ein oder anderen Bug zu finden...
-
Nichtsdestotrotz, pflegt man die Tools, helfen Sie durchaus den ein oder anderen Bug zu finden...
Dieser Meinung bin ich auch.
-
384 kb Flash?
Könnte sich das nicht zu einem Größen-Problem entwickeln wenn man zuviele Dinge von C/C++ (printf, std::locale) nutzt?
-
Bitte ein Bit schrieb:
384 kb Flash?
Könnte sich das nicht zu einem Größen-Problem entwickeln wenn man zuviele Dinge von C/C++ (printf, std::locale) nutzt?
printf und co gibt es bei uns gar nicht da wie du schon festgestellt hast der Speicher knapp wird.
Wir haben unser eigenes Logging Modul, dass nur kodiertes Zeug über UART auswirft. Es gibt dann ein externes Tool das die Ausgaben wandelt und anzeigt...
Und ja, wir kämpfen um jedes Bit... ;).
Gruß
Tobi