Hallo, auf der letzten Embedded World Conference wurden statische Code Analyse Tools als das Allheilmittel angepriesen. Meine (zugegeben bereits ca. 10 Jahre alten) Erfahrungen mit solchen Tools waren eher ernüchternd. Meiner Meinung nach finden die eher Anfängerfehler, liefern jede Menge false positives und haben selbst wieder einiges an Bugs, für die man Workarounds braucht. Nutzt jemand von euch solche Tools wirklich erfolgreich (insbesondere mit C++) und würde eins empfehlen? mfg Torsten
Beim gcc erstmal alles, was sinnvoll erscheint, scharf schalten. In Stufe 2 dann clang. Damit haben wir schon sehr viele Flüchtigkeitsfehler gefunden und behoben.
The D. schrieb: > Beim gcc erstmal alles, was sinnvoll erscheint, scharf schalten. In > Stufe 2 dann clang. Damit haben wir schon sehr viele Flüchtigkeitsfehler > gefunden und behoben. Ja, stimmt. Die Compiler sind mittlerweile in dem Bereich auch schon sehr gut.
Dem kann ich mich nur anschliessen. Was auch geholfen hat, bei einem Projekt erches als Zielplatform VxW/PXA270 hatte: Quellcode von Anfang an portabel schreiben. Windriver lieferte (damals, zu VxW 6.5/6.7) nur ein GCC 4.2 mit, unser Code konnten wir aber auch unter Cygwin und Linux mit neueren GCCs (Clang war noch nicht Spruchreif) f. x86 compilieren (auch ausführen :). Der knapp 10% Mehraufwand f.d. Portabilität hat sich in sauberer Programmarchitektur, mehr/schärferen Warnings (die wir nicht stehen liessen), mehr UND besseres Fehlerfinden (komfortableres Debugging, Laufzeitunterschiede der Plattformen) echt mehrfach bezahlt gemacht. Zus. CI & Testautomation macht guten, ruhigen Schlaf in der Nacht, JEDE Nacht! :-) Ich denke statische Codeanalyse funktioniert nur/eher bei bereits einigermassen sauberen Programmstrukturen. Geröllhaldenwracks können solche Tools auch nicht von alleine "heilen".
Probier mal den hier aus: http://cppcheck.sourceforge.net/ Den lassen wir normal einfach mitlaufen. Er erkennt natürlich nicht alles, aber vor allem steht er einem auch bei komplexeren C++-Konstrukten, Boost etc. nicht im Weg. Hat aber schon öfters was gefunden was wir übersehen haben.
Gerd E. schrieb: > Probier mal den hier aus: > http://cppcheck.sourceforge.net/ ich habe hier so ein Paradebeispiel, das meiner Meinung nach von jedem Tools gefunden werden müsste, wenn es behauptet, statische Code Analyse auf C++ machen zu können:
1 | #include <vector> |
2 | |
3 | void f() |
4 | {
|
5 | std::vector< int > c = { 1, 2, 3 };
|
6 | auto pos = c.begin(); |
7 | |
8 | c.push_back( 4 ); // *1 |
9 | |
10 | *pos = 0; // u.b.! |
11 | } |
Da hat CppCheck nix gefunden. Aber für den Preis, ist das akzeptabel ;-)
Nur mal rein interessehalber, was kosten denn die Tools, die solche Fehler finden? Oliver
Netter Test. Werde ich mal unserem tool zum Fraß vorwerfen. Bin gespannt.
Oliver S. schrieb: > Nur mal rein interessehalber, was kosten denn die Tools, die solche > Fehler finden? Es gibt da von bis. PC-Lint kostet ca. 100$, andere Tools kosten aber auch gerne mal 10.000€.
Es gab mal vor ein paar Jahren einen Thread dazu: Beitrag "Statische Codeanalyse für den Hobbyprogrammierer" Die Nachwirkungen dieses Threads sind bei mir, daß ich alle Projekte, die auch für den PC kompilierbar sind, mit dem statischen Codeanalysewerkzeug von Clang/LLVM noch einmal gegenteste. Es findet wirklich ab und an Sachen, bei denen auch maximale Compilerwarnungen nichts gefunden hätten. Fazit für mich: Es ist ein weiteres nützliches Werkzeug in meinem Werkzeugkasten geworden.
Torsten R. schrieb: > Oliver S. schrieb: >> Nur mal rein interessehalber, was kosten denn die Tools, die solche >> Fehler finden? > > Es gibt da von bis. PC-Lint kostet ca. 100$, andere Tools kosten aber > auch gerne mal 10.000€. Lint hatten wir auch mal am Start. Lang ists her, man war eigentlich nur mit der Bekämpfung der false positives beschäftigt.
Ingo L. schrieb: > und ich versteh das Beispiel nichtmal :D Der Punkt ist, dass `pos` ein Iterator ist, der ungültig werden kann, wenn der vector bei *1 an seine Kapazitätsgrenzen kommt und realoziieren muss. Dann wird der vector neuen Speicher anfordern, den Inhalt des vectors in den neuen Speicher kopieren und den alten Speicher frei geben. Der Iterator wird aber noch in alten Speicher zeigen. Das "blöde" an dem Fehler ist, dass er nur selten auftreten wird und auch bei Tests nicht unbedingt auffallen wird. Bei Code-Reviews sollte so etwas auffallen.
Ingo L. schrieb: > Torsten R. schrieb: >> Da hat CppCheck nix gefunden > und ich versteh das Beispiel nichtmal :D Der Iterator pos ist ungültig nachdem vector c verändert wurde. Gruß Martin
Torsten R. schrieb: > gibt da von bis. PC-Lint kostet ca. 100$, andere Tools kosten aber > auch gerne mal 10.000€. Das war nicht die Frage... Die Frage war, was Tools kosten, die den Fehler im gezeigten Code finden. Oliver
Oliver S. schrieb: > Die Frage war, was Tools kosten, die den Fehler im gezeigten Code > finden. Ich kenne nicht mal ein Tools, dass solche Fehler findet.
Torsten R. schrieb: > Oliver S. schrieb: >> Die Frage war, was Tools kosten, die den Fehler im gezeigten Code >> finden. > > Ich kenne nicht mal ein Tools, dass solche Fehler findet. Angeblich soll das mit den C++ Core Guidelines und entsprechendem Tool gefunden werden. Es gibt dazu einen interessanten Vortrag von Herb Sutter: https://www.youtube.com/watch?v=hEx5DNLWGgA Hier in den Folien (https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Sutter%20-%20CppCon%202015%20day%202%20plenary%20.pdf) auf Folie 44 wird quasi genau das gleiche Beispiel gebracht.
Torsten R. schrieb: > ich habe hier so ein Paradebeispiel, das meiner Meinung nach von jedem > Tools gefunden werden müsste, wenn es behauptet, statische Code Analyse > auf C++ machen zu können: > >
1 | > #include <vector> |
2 | > |
3 | > void f() |
4 | > {
|
5 | > std::vector< int > c = { 1, 2, 3 };
|
6 | > auto pos = c.begin(); |
7 | > |
8 | > c.push_back( 4 ); // *1 |
9 | > |
10 | > *pos = 0; // u.b.! |
11 | > } |
12 | > |
In Deinem Paradebeispiel sollte ein Tool vor allem auch die völlig nichtssagenden Kommentare kritisieren. ;-)
Hallo Sebastian, Sebastian V. schrieb: > Angeblich soll das mit den C++ Core Guidelines und entsprechendem Tool > gefunden werden. Es gibt dazu einen interessanten Vortrag von Herb > Sutter: https://www.youtube.com/watch?v=hEx5DNLWGgA super, habe ich mir gerade angeguckt. Microsoft arbeitet offensichtlich gerade an einem static analyser, der genau solche Fehler finden kann. Spannend :-) mfg Torsten
Mark B. schrieb: > In Deinem Paradebeispiel sollte ein Tool vor allem auch die völlig > nichtssagenden Kommentare kritisieren. ;-) Ja, das Beispiel war aus einer Mail kopiert. Ich finde es ja schon immer spannend, dass manche IDEs schon Rechtschreibfehler in Kommentaren finden :-)
Adib schrieb: > QAC kostet ca 4.500€. Einmalig oder jährlich? Ich bin diesen tools gegenüber eher kritisch eingestellt. Am Ende muss man doch selber mit dem 4-Augenprinzip ran.
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.