Hallo zusammen,
gestern habe ich die Werbebrochüre für ein Werkzeug zur statischen
Codeanalyse bekommen und ich frage mich, ob soetwas auch für den
Hobbybereich mit vertretbarem Aufwand einsetzbar ist - zumal mir ein
ähnliches Werkzeug in Fortran und Matlab schon viel geholfen hat.
Ich selbst nutze den AVR-GCC (unter Atmel Studio) und den ARM-GCC (unter
CooCox).
Splint scheint seit 2007 verlassen zu sein.
PC-Lint ist ein Werkzeug für 390USD (vielleicht nicht gerade angebracht
für die ersten Versuche).
Polyspace scheint im oberen Preissegment angesiedelt zu sein.
Gibt es irgendein Werkzeug, bei dem die Einstiegshürde nicht zu hoch
ist? Problematisch ist ja, daß so ein Werkzeug gerade dem besonders
hilft, für den die Einrichtung eine große Hürde ist.
Viele Grüße
W.T.
Mark Brandis schrieb:> Wikipedia hat eine ganze Liste von solchen Tools
Du hast das Problem auf den Punkt gebracht: Es ist eine sehr lange Liste
von Werkzeugen. Zuviele, um sie alle anzuschauen, um die beste Lösung zu
finden.
cppcheck importiert bei mir nur ein drittel der Dateien ein. Woran kann
das liegen? System ist Windows 7 64bit, volle Adminrechte. Am Dateinamen
kann es nicht liegen, z.B.: PROTOCOL_RX.C wird importiert, PROTOCOL_TX.C
hingegen nicht.
Schade, das Tool sah viel versprechend aus.
Walter Tarpan schrieb:> Du hast das Problem auf den Punkt gebracht: Es ist eine sehr lange Liste> von Werkzeugen. Zuviele, um sie alle anzuschauen, um die beste Lösung zu> finden.
"Die beste Lösung" wird man wohl kaum finden können, ohne einen gewissen
Aufwand zu betreiben. Da kann man auch verlangen, dass einem die
gebratenen Tauben in den Mund fliegen sollen. ;-)
Mark Brandis schrieb:> Da kann man auch verlangen, dass einem die> gebratenen Tauben in den Mund fliegen sollen.
Nein, verlangen kann man nichts. Aber man kann hoffen, daß in einem
Werkzeugforum Menschen gerne Tipps geben, welches Werkzeug sie benutzen.
Aber scheinbar wird hier so ein Werkzeug nicht gerne oder nicht oft
benutzt.
Viele Grüße
W.T.
Walter Tarpan schrieb:> scheint ja nicht so dolle zu seinWalter Tarpan schrieb:> Aber scheinbar wird hier so ein Werkzeug nicht gerne oder nicht oft> benutzt
Scheinbar gibt es da einen Zusammenhang...
Oliver
Oliver S. schrieb:> Walter Tarpan schrieb:> scheint ja nicht so dolle zu sein>> Walter Tarpan schrieb:> Aber scheinbar wird hier so ein Werkzeug nicht gerne oder nicht oft> benutzt>> Scheinbar gibt es da einen Zusammenhang...>> Oliver
Mitnichten.
Du willst damit wohl suggerieren dass das Werkzeug "statische
Codeanalyse" hier nicht oft benutzt wird weil es nicht so toll wär.
Ich würde sagen, es wird hier nicht oft benutzt weil viele schlicht
nicht wissen dass es sowas gibt, oder einfach drauf sch...
@Topic: splint hat bei mir mal ganz gut geklappt. Wenn das natürlich
nicht mehr weiterentwickelt wird wär das schade.
Du musst dir auf jeden Fall Zeit nehmen das Teil einzurichten. Ansonsten
wirst du mit Warnungen überhäuft ;-)
Ben schrieb:> @Topic: splint hat bei mir mal ganz gut geklappt. Wenn das natürlich> nicht mehr weiterentwickelt wird wär das schade.
Die letzte Änderung wird auf den 12. Juli 2007 datiert, das
Sourceforge-Repository existiert nicht (mehr?).
http://www.splint.org/changes.html
Also vermutlich mal wieder ein schönes Projekt, das verwaist ist.
Walter Tarpan schrieb:> Also vermutlich mal wieder ein schönes Projekt, das verwaist ist.
Wohl eher vom Lauf der Zeit überrollt. Aktuelle C/C++-Compiler erkennen
inzwischen selber einen Großteil der Fehler, für die lint und Konsorten
ursprünglich erdacht wurden.
Oliver
PC-Lint ist schon zu empfehlen. Es erkennt viele Dinge
über die der ARM-Keil-Compiler der eigentlich ein guter ist
(kommt direkt von ARM) hinwegsieht.
Hinzu kommt sein Fast-Alleinstellungsmerkmal wenn man auf C++
abzielt.
Walter Tarpan schrieb:> Aber scheinbar wird hier so ein Werkzeug nicht gerne oder nicht oft> benutzt.
Im Beruf wird das durchaus genutzt, aber da stellt in der Regel die
Firma ein (kommerzielles) Tool bereit.
Privat verlasse ich mich zugegeben gerne auf "-Wall -Wextra" bei den
Compiler-Einstellungen, wenn es um C bzw. C++ geht und auch ansonsten
arbeite ich penibel sämtliche Warnungen ab, die mir irgendein Compiler
(z.B. javac) an der Kopf wirft. Meistens reicht das.
Mark Brandis schrieb:> Im Beruf wird das durchaus genutzt, aber da stellt in der Regel die> Firma ein (kommerzielles) Tool bereit.
Ich kenne genug Entwickler, die sowas gar nicht kennen.
Da kommen dann schnell solche Sprüche:
"sowas braucht man doch nicht..."
"du kannst wohl nicht richtig programmieren..."
"das macht alles der Compiler..."
"sowas ist nur Geldmacherei..."
Und nein diese Personen sind nicht Ü50! Gerade junge Leute lernen sowas
im Studium gar nicht mehr kennen.
Wenn ich dann noch sage, dass ich einen Debugger / Emulator im Büro
stehen habe und diese Dinge auch noch nutze oh je oh je.
Bei knapp 520€ für PC-Lint mit graphischer Oberfläche konnte sich das
mein Arbeitgeber gerade so leisten ;-)
Mark Brandis schrieb:> Im Beruf wird das durchaus genutzt, aber da stellt in der Regel die> Firma ein (kommerzielles) Tool bereit.
Soetwas hatte ich schon befürchtet.
PC-Lint ist für den kommerziellen Einsatz wirklich als preisgünstig
anzusehen- allerdings scheint es keine educational-Version zu geben.
Cppcheck hat in meinem (für mich) riesigen Projektbaum gerade mal einen
einizgen erstzunehmenden Fehler gefunden:
1
staticuint8_trampe(int16_tdiff){
2
//diff > 0
3
//gl_iVel Geschwindigkeitsindex
4
int8_taiv;// Absolutwert Geschwindigkeitsindex
5
6
if(diff>gl_iVel){// Bei grosser Distanz beschleunigen
7
gl_iVel++;
8
if(gl_iVel==N_RAMPSTEPS)gl_iVel=N_RAMPSTEPS-1;
9
}
10
elseif(diff>gl_iVel){// Wenn Distanz kleiner bremsen
11
gl_iVel--;
12
if(gl_iVel==-N_RAMPSTEPS)gl_iVel=-N_RAMPSTEPS+1;
13
}
14
15
aiv=gl_iVel<0?-gl_iVel:gl_iVel;
16
returnramp[aiv];
17
}
und ist damit für mich nicht mehr ernstzunehmen (wobei ich froh bin, den
Fehler gezeigt bekommen zu haben, bevor ich die Auswirkungen bemerken
konnte).
-Wall, -Wextra und -Wpedantic gehören für mich zur Standardausstattung
(wobei mmir letzteres wegen einiger selbst-definierter Escapcesequenzen
manchmal auf den Geist geht). Den Logik-Fehler oben hat mir aber keiner
gemeldet.
Walter Tarpan schrieb:> Cppcheck hat in meinem (für mich) riesigen Projektbaum gerade mal einen> einizgen erstzunehmenden Fehler gefunden:
So gehts mit auch. Ich hab mein aktuelles Hobbyprojekt mal duchgeschoben
(ca. je 50 Source- und Header-Dateien), und zwei "Probleme" gefunden.
Das eine hatte schon ein TODO dran (fehlende realloc-Fehlerbehandlung),
das andere steckte in einer quick-and dirty-Testroutine (pointer am
Programmende nicht deleted, aber der Compiler räumt nach Beedigung des
Programms eh auf ;)
Ich bin allerdings so ehrlich, zuzugeben, daß das das Ergebnis nicht an
meinen überragenden ;) Programmierkenntnissen liegen kann.
Oliver
Walter Tarpan schrieb:> Den Logik-Fehler oben hat mir aber keiner gemeldet.
Der GCC 4.4 hätte dir für die beiden Anweisungen nach der fehlerhaften
If-Bedingung ein "will never be executed" geliefert. Mit der Version 4.5
wurde dies Warnmeldung leider zu Grabe getragen. Der Compiler optimiert
die entsprechenden Codezeilen zwar nach wie vor weg, informiert dich
aber nicht darüber.
Siehe auch:
http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
Oliver S. schrieb:> Das eine hatte schon ein TODO dran (fehlende realloc-Fehlerbehandlung),
Tja, und ein paar Zeilen weiter hatte ich dann noch ein realloc, ohne
TODO. Vermutlich deshalb hat cppcheck das nicht gefunden ;)
Walter Tarpan schrieb:> scheint ja nicht so dolle zu sein
Scheint so...
Oliver
Naja, einestatische Analyse findet nicht alles. Für kostenlos kann man
es aber im build mitlaufen lassen. Dafür hat EA einen Vorteil, es ist
quasi false positive frei.
us73 schrieb:> http://clang-analyzer.llvm.org/
Nachdem ich so diverse Warnungen gesehen habe, die clang produziert,
die für einen GCC nie ein Problem waren (obwohl völlig berechtigt),
würde ich mal ein "+1" für clang hier setzen. Sollte man sich auf
jeden Fall mal angucken, wenn man in dieser Richtung unterwegs ist.
Für Clang ist die Einstiegshürde wohl etwas höher; vor allem, wenn man
in der Windows-Welt zuhause ist.
Um selbstgeschriebene Makefiles scheint man auch zu brauchen.
Also schiebe ich das mal auf eine mehr mittel- als kurzfristige Planung.
Danke für den Tip!
Walter Tarpan schrieb:> Für Clang ist die Einstiegshürde wohl etwas höher; vor allem, wenn man> in der Windows-Welt zuhause ist.
Da habe ich keine Ahnung. Ich aktualisiere mein System gerade auf eine
FreeBSD-Version 10, da ist clang mittlerweile der Standardcompiler. ;)
> Um selbstgeschriebene Makefiles scheint man auch zu brauchen.
Wie das mit der Codeanalyse aussieht, habe ich mir noch nicht angesehen,
aber ansonsten ist clang wohl verdammt aufrufkompatibel mit dem GCC.
Walter Tarpan schrieb:> Für Clang ist die Einstiegshürde wohl etwas höher; vor allem, wenn man> in der Windows-Welt zuhause ist.
Ich hab gestern spasseshalber mal eine Windows-"Installation"
angefangen. Nach einer halben Stunde svn sourcen laden was der damit
immer noch nicht fertig. Compilieren dürfte da tagelang dauern, und dazu
kommt noch das übliche Linux-Kleingedruckte (please install Python,
Perl, gnutools, ....) Ich hab das dann abgebrochen.
Das mag ja ein toller Compiler sein, aber so ist das wie die
Harald-Schmidt-Show auf Sky: Unter völligem Ausschluß der
Öffentlichkeit.
Oliver
Oliver S. schrieb:> Ich hab gestern spasseshalber mal eine Windows-"Installation"> angefangen. Nach einer halben Stunde svn sourcen laden was der damit> immer noch nicht fertig.
Wenn du das eigentlich gar nicht haben willst, warum holst du dir denn
dann unbedingt einen SVN-Snapshot? Für den braucht man auch beim GCC
übrigens schnell mal eine halbe Stunde oder länger, selbst an einer
guten Internetleitung.
Wenn ich dort auf "Get Clang" gehe, dann bekommt man doch auch Releases
und sogar fertige Windows-Binaries.
Ich versteh' das Gejammer der "wir sind hier aber außen vor"-Fraktion
nun gar nicht mehr.
(Davon abgesehen: für Compiler-Entwickler waren und sind unixoide
Systeme nun einmal schon immer die erste Wahl als Basis. Das hat mir
letztens sogar jemand von IAR so bestätigt.)
Jörg Wunsch schrieb:> Wenn du das eigentlich gar nicht haben willst, warum holst du dir denn> dann unbedingt einen SVN-Snapshot?
Ok, war mißverständlich, ich wollte den clang-analyzer, und der muß halt
aus den clang-Quellen gebaut werden. clang selber gibt es als
Windows-Installer.
> Ich versteh' das Gejammer der "wir sind hier aber außen vor"-Fraktion> nun gar nicht mehr.
Na ja, das klingt wie der Mathematiker im Käfig, der sich dadurch
"befreit", daß er einfach "drinnen" in "draussen" umdefiniert ;)
Oliver
Oliver S. schrieb:> Ok, war mißverständlich, ich wollte den clang-analyzer, und der muß halt> aus den clang-Quellen gebaut werden.
Aber auch die muss man sich doch nicht zwingend aus dem SVN ziehen,
sondern man kann auch einen Release-Tarball nehmen. Sollte deutlich
einfacher und schneller sein.
> Na ja, das klingt wie der Mathematiker im Käfig, der sich dadurch> "befreit", daß er einfach "drinnen" in "draussen" umdefiniert ;)
Bliebe nur die Frage, wer von uns beiden der Mathematiker ist. ;-)
Ich jedenfalls habe keine Probleme, die Software zu benutzen, die
ich brauche ...
Jörg Wunsch schrieb:> Aber auch die muss man sich doch nicht zwingend aus dem SVN ziehen,> sondern man kann auch einen Release-Tarball nehmen. Sollte deutlich> einfacher und schneller sein.
Kann durchaus sein. Da ich aber ausserhalb des Käfigs lebe, fehlt mir
das enstprechende Insiderwissen, und habe ich mich schlicht an die
Installationsanweisung von denen gehalten. Die fängt nun mal mit "load
the sources from svn" an.
Oliver
Oliver S. schrieb:> Kann durchaus sein. Da ich aber ausserhalb des Käfigs lebe, fehlt mir> das enstprechende Insiderwissen, und habe ich mich schlicht an die> Installationsanweisung von denen gehalten. Die fängt nun mal mit "load> the sources from svn" an.
Hmm, „Insiderwissen“ bezüglich llvm/clang habe ich auch keins.
Aber verhindert der Aufenthalt im Windows-Käfig wirklich das Nachdenken?
Da steht zwar am Anfang, dass man sich ein clang bauen soll, stimmt.
Warum kann man von diesem Punkt aus aber nicht auf die Idee kommen, dass
es ein vorgefertigter, vorhandener Build von clang das nicht auch tun
könnte? (Zumal ja keinerlei Anweisungen gegeben werden, dass der Build
für den Analyzer irgendwelche besonderen Zusatzoptionen bräuchte.)
Weiter
geht's ja in den Anweisungen mit:
1
Once the Clang is built, you need to add the following to your path:
Einzig die beiden Tools scan-build und scan-view muss man sich aus dem
Sourcecode extrahieren (das steht aber auch so geschrieben, sie werden
derzeit eben noch nicht automatisch ins Zielsystem installiert). Aber
das bisschen clang-Sourcecode (10 MiB) ist relativ schnell geladen.
Auch das wiederum kann man sich vom jeweils aktuellen Release laden.
In der Tat funktioniert ein vorgefertigtes Binary problemlos, man muss
es halt ggf. mit --use-analyzer dem scan-build-Script bekanntmachen
(aber das sagt er einem auch, wenn er kein clang findet).
Die größte Hürde für Windows dürfte eigentlich die Installation von
Perl sein, denn scan-build und scan-view (die beiden Analyzer-Scripte)
sind halt Perlscripte.
Anbei ein Screenshot von scan-view für eine Datei, in die ich mal
absichtlich zwei Fehler gebaut habe.
Jörg Wunsch schrieb:>> [...]> Aber verhindert der Aufenthalt im Windows-Käfig wirklich das Nachdenken?> Da steht zwar am Anfang, dass man sich ein clang bauen soll, stimmt.> Warum kann man von diesem Punkt aus aber nicht auf die Idee kommen, dass> es ein vorgefertigter, vorhandener Build von clang das nicht auch tun> könnte?>> [...]
Ehrlich gesagt: Ich habe die Binaries auch nicht gesehen, bevor Du nicht
erwähntest, daß es sie gibt. Wenn man gezielt sucht, sind sie zu finden.
Sie sind übrigens hier: http://llvm.org/releases/download.html
Vorher gingen meine Gedanken auch in Richtung:
- "OK, Du brauchst Visual Studio 2012"
- "hoffentlich beißt sich das nicht mit den beiden anderen Visual
Studios (Visual Studio 2010 Prof. und Atmel Studio)"
- "Vielleicht eine virtuelle Maschine für den Build aufsetzen?
- "oder vielleicht eine virtuelle Maschine für Linux"
- "Vielleicht mal wieder ein Cygwin oder KDE Win installieren - dann
hast Du auch endlich wieder XFig (das einzige Linux-Programm, das ich in
der Windows-Welt wirklich vermisse)"
- "nee, cygwin geht laut Anleitung nicht"
- "OK, verschieben wir das Ganze."
Wenn sich jemand aus dem Projekt die Mühe macht, eine komplizierte
Anleitung zu schreiben, gehe ich erst einmal davon aus, daß es momentan
der einfachste Weg ist.
Aber es ist schön, daß dem nicht so ist. So ließ sich clang total
problemlos installieren und ist jetzt per Kommandozeile verfügbar. Also
als nächstes schaun wir mal, wie sich der Analyzer hinzufügen läßt.
Viele Grüße
W.T.
Walter Tarpan schrieb:> Also als nächstes schaun wir mal, wie sich der Analyzer hinzufügen läßt.
Den brauchst du eigentlich nur aufrufbar machen (also die beiden
Perlscripte). Keine Ahnung, wie man das unter Windows macht, unter
Unix läuft die Verknüpfung vom Script zum Interpreter ja über die
#!-Zeile ganz oben. (Eventuell musst du sie unter Windows in .pl
umbenennen, denn mit einer ordentlichen Endung bekommt Windows wieder
die Zuordnung auf die Reihe.)
Der erste Script ist so konzipiert, dass man ihn dem normalen Aufruf
seines Builds voranstellt. Wenn man also sonst "make" sagt, dann
sagt man für den Analyzer "scan-build make". (Bei der make-basierten
Variante ist es wohl wichtig, dass das Makefile nicht die Variable
CC überschreibt, denn die wollen sie mit dem für die analyse zu
benutzenden Compiler überschreiben können.)
Der zweite wertet dann nur die vom ersten hinterlassenen Daten über
den Browser aus.
Ich kriege dieses Perl-Script unter Windows einfach nicht ans Laufen.
Gibt es eine empfehlenswerte Linux-Distribution für den kleinen Test so
zwischendurch in einer virtuellen Maschine? Debian?
Walter Tarpan schrieb:> Ich kriege dieses Perl-Script unter Windows einfach nicht ans Laufen.
Was passiert denn genau damit?
> Gibt es eine empfehlenswerte Linux-Distribution für den kleinen Test so> zwischendurch in einer virtuellen Maschine? Debian?
Hängt von deinem Geschmack ab. Wenn du sowas wie Ubuntu oder Mint
nimmst, dann hast du den besten Komfort in Richtung Desktop, aber der
kostet natürlich Speicher und CPU-Zyklen. Je einfacher du dahingehend
wirst, um so weniger Ressourcen brauchst du, aber um so schwerer wirst
du dich als jemand, der sonst Windows macht, damit tun. Kann man
abrüsten bis zu Systemen mit reiner Textconsole.
Jörg Wunsch schrieb:> Kann man> abrüsten bis zu Systemen mit reiner Textconsole.
Naja, bis auf Cppcheck sind ja alle Codeanalysetools, die ich testen
kann, eh kommandozeilenbasiert. Also brauche ich ja nur Clang, Apt und
Make.
Windows-Nutzer zu sein hat ja nichts damit zu tun, die Kommandozeile zu
schätzen zu wissen.
Momentan lade ich Debian herunter. Ich halte es für sinnlos, soetwas auf
meinem Raspherry machen zu wollen.
Um die Tools an einzelnen Dateien zu testen, brauchst du die
Perl-Skripte nicht unbedingt. Sie dienen hauptsächlich dazu, die Analyse
automatisch innerhalb eines Build-Prozesses eines größeren Projekts mit
den richtigen Präprozesor-Defines auf alle beteiligten Quellcodedateien
anzuwenden.
Letztendlich ruft das Skript auch nur clang auf.
Da ich gerade nicht vor einem richtigen PC sitze, kann ich dir den
genauen Aufruf nicht sagen. Soweit ich mich aber erinnere, ruft das
Perl-Skript so etwas wie
1
clang -analyze <viele weitere Optionen> <Dateiname>
Yalu X. schrieb:> Um die Tools an einzelnen Dateien zu testen, brauchst du die> Perl-Skripte nicht unbedingt. Sie dienen hauptsächlich dazu, die Analyse> automatisch innerhalb eines Build-Prozesses eines größeren Projekts mit> den richtigen Präprozesor-Defines auf alle beteiligten Quellcodedateien> anzuwenden.>> Letztendlich ruft das Skript auch nur clang auf.>> Da ich gerade nicht vor einem richtigen PC sitze, kann ich dir den> genauen Aufruf nicht sagen. Soweit ich mich aber erinnere, ruft das> Perl-Skript so etwas wie> clang -analyze <viele weitere Optionen> <Dateiname>>> auf.
Hallo Yalu,
danke für den Tipp! Ja, einzelne Dateien lassen sich so schön
überprüfen.
Und bei meinem einfachen Testfall von oben (siehe
Beitrag "Re: Statische Codeanalyse für den Hobbyprogrammierer" ), wo der cppcheck
so versagt hat, kriege ich sinnvolle Meldungen.
Jetzt habe ich den Debian allerdings so weit am Laufen... da ist die
"Hürde" nur noch, das vom AVR-Studio erzeugte Makefile auf relative
Pfade umzuschreiben.
Und die Windows-Variante reicht für den kleinen Test zwischendurch.
Eigentlich besser, als ich es mir erhofft habe.
Ich hätte nicht gedacht, diese Wochenende doch schon sinnvolle
Ergebnisse zu haben. Jetzt geht es mal fleißig ans Testen.
Haro schrieb:> Habe ich einen Denkfehler, bin ich blind, oder ist es wirklich so, dass> der analyzer die Nullpointer-Dereferenzierung nicht anmeckert?
Musste es jetzt selbst erstmal probieren, aber zumindest für den
einfachen Testfall meckert er das sehr wohl an.
Jörg Wunsch schrieb:> Haro schrieb:>>> Habe ich einen Denkfehler, bin ich blind, oder ist es wirklich so, dass>> der analyzer die Nullpointer-Dereferenzierung nicht anmeckert?>> Musste es jetzt selbst erstmal probieren, aber zumindest für den> einfachen Testfall meckert er das sehr wohl an.
Ich bezog mich dabei auf deinen ersten Test:
Beitrag "Re: Statische Codeanalyse für den Hobbyprogrammierer"
Dort wird ja der Zeiger x, der mit NULL initialisiert wird,
dereferenziert.
Haro schrieb:> Ich bezog mich dabei auf deinen ersten Test:
Da wurde auch noch ein zweiter Fehler angezeigt, habe aber vergessen,
was das war.
Bei der Ansicht war ich dann nur in die Details gegangen, sodass man
nur noch eine der beiden Beschwerden sieht.
Hallo zusammen,
gerade mal ein Jahr und eine Woche später bin ich so weit, das Ganze mal
ernsthaft ausprobiert zu haben. Die Zwischenzeit hat (neben einer langen
Projektpause) vor allem der Prozeß gebraucht, einen Mikrocontroller-Code
auf den PC zu bringen - mit allen Stubs, einem neuen Build-Prozeß und
dem ganzen Kram, der dazu notwendig ist.
Hat sich das Ganze gelohnt? Jein.
Teil der ganzen Aktion war es, daß sich jetzt der Quelltext auch mit dem
Clang unter Linux bauen läßt. Der ist mit seinen detaillierten
Fehlermeldungen eine große Hilfe und kann einige Tipps geben, die der
GCC selbst -pedantisch für sich behält.
Natürlich ist auch der Prozeß, ein µC-Programm auf den PC zu bringen
sehr lehrreich - hatte ich bislang noch nie für den PC programmiert -
und ich lerne noch täglich dazu.
Die statische Codeanalyse selbst ist allerdings etwas enttäuschend. Bei
so einer Funktion hatte er überhaupt nicht anzumeckern (Fehler mit
Absicht eingebaut):
1
uint8_tlimadd_uint8(uint8_ta,int8_t)
2
{
3
int8_ttemp=a+b;
4
if(temp>(int16_t)UINT8_MAX){
5
temp=UINT8_MAX;
6
}
7
elseif(temp<0){
8
temp=0;
9
}
10
11
returntemp;
12
}
Hier hatten weder die Codeanalyse noch Clang (3.5) etwas auszusetzen.
Andererseits sind die false positives für mich regelrecht
unverständlich (siehe z.B. angehängter Screenshot): Hier wird das
Werkzeug durch das assert-Makro mit der Nase darauf gestoßen, daß
"readbuffer" kein Nullzeiger sein kann - und nimmt trotzdem genau das
Gegenteil an.
Sehr überzeugend ist allerdings die Nutzung dieses Werkzeugs. Für ein
auf der entsprechenden Plattform /build/-bares Programm das make-Skript
einfach über ein anderes Programm aufzurufen und sich dann die Meldungen
bequem im Browser anszusehen ist meiner Meinung nach ein sehr bequemes
Bedienkonzept, ohne daß dafür eine spezielle IDE notwendig wäre. Hier
ein klarer Pluspunkt.
Mein Fazit bislang: Das Werkzeug ist deswegen gut, weil es - für
PC-Programme - kaum Mehraufwand bedingt. Der Nutzen ist allerdings
begrenzt - und zwar noch mehr, als ich im Vornherein erwartet habe.
Viele Grüße
W.T.
> Hier wird das Werkzeug durch das assert-Makro mit der Nase darauf> gestoßen, daß "readbuffer" kein Nullzeiger sein kann
∗hüstel∗ noch einer der assert() nicht verstanden hat und die Doku dazu
nicht gelesen hat.
Walter Tarpan schrieb:> uint8_t limadd_uint8(uint8_t a, int8_t)> {> int8_t temp = a + b;> if (temp > (int16_t) UINT8_MAX) {> temp = UINT8_MAX;> }> else if (temp < 0) {> temp = 0;> }>> return temp;> }
Wenn das so ungestreift durch den Compiler geht, hast Du wohl noch
irgendwo ein (globales oder statisches) b rumliegen.
Markus F. schrieb:> Walter Tarpan schrieb:>> [...]>> Wenn das so ungestreift durch den Compiler geht, hast Du wohl noch> irgendwo ein (globales oder statisches) b rumliegen.
Nein, da kam noch ein Tippfehler dazu. Sollte heißen:
1
uint8_tlimadd_uint8(uint8_ta,int8_tb)
2
{
3
int8_ttemp=a+b;
4
if(temp>(int16_t)UINT8_MAX){
5
temp=UINT8_MAX;
6
}
7
elseif(temp<0){
8
temp=0;
9
}
10
11
returntemp;
12
}
g457 schrieb:> ∗hüstel∗ noch einer der assert() nicht verstanden hat und die Doku dazu> nicht gelesen hat.
Kannst Du das etwas genauer erläutern? Nach dem, was ich gelesen habe,
sollte eine unerfüllte Assertion dazu führen, daß der Prozeß anhält und
Feuer fängt und damit alles was danach kommt sicher sein können, nie
ausgeführt zu werden.
> Kannst Du das etwas genauer erläutern? [..] alles was danach kommt sicher> sein können, nie ausgeführt zu werden.
assert() ist sehr praktisch solange man am debuggen ist weil dann
$debugger das Programm anhält, die IDE an $codestellste springt und man
den aufgetretenen Fehler in vivo präsentiert bekommt. Aber es ist nicht
dafür vorgesehen, im finalen Code zu verbleiben, macht ja auch keinen
Sinn. Die üblichen(tm) Umgebungen setzen das dafür nötige NDEBUG im
"release-Modus" per default, was bewirkt, dass das assert()-Statement
dort zur Compilezeit(!) komplett wegfällt.
Der langen Rede kurzer Sinn: Man darf sich ∗nicht∗ darauf verlassen,
dass es beim assert() tatsächlich nicht weitergeht, sofern man nicht
extra dafür vorgesorgt hat. Wenn man es trotzdem tut schreibt man extrem
fehleranfälligen Code.
g457 schrieb:> er langen Rede kurzer Sinn: Man darf sich ∗nicht∗ darauf verlassen,> dass es beim assert() tatsächlich nicht weitergeht, sofern man nicht> extra dafür vorgesorgt hat.
Ich glaube darin sind sich alle Nutzer einig. Das assert stellt
lediglich sicher, daß bei allen Programm-Tests eine Bedingung immer
erfüllt war - ansonsten hätten sich Annahmen, die dem assert
zugrundelagen, als unzutreffend herausgestellt und die Codestelle hätte
geändert werden gemußt.
Was für mich im Umkehrschluß heißt: Das assert ist noch drin, also hat
die Bedingung bislang immer zugetroffen (denn hätte sie einmal nicht
zugetroffen, hätte der Code eh geändert werden müssen). Also kann der
Code danach erst einmal davon ausgehen, daß die Bedingung immer erfüllt
ist.
Naja, vielleicht sieht der Code-Analyzer das anders - dann würde mich
aber interessieren, wie.
> Also kann der Code danach erst einmal davon ausgehen, daß die Bedingung> immer erfüllt ist.
Nein, nur für die Fälle, die Du tatsächlich abgetestet hast. Und ich
kann mir nicht vorstellen, dass Du in obigem Beispiel mit malloc()
∗alle∗ möglichen Kombinationen von Speicherbelegungen abgetestet hast.
Assert() nur solange der Debugger dranhängt, ansonsten richtig(tm)
machen.
Vielleicht ist der false positive etwas ungünstig gewählt, weil er
durchaus auch als korrekter Treffer gewertet werden kann.
Aber wie kann ein Codeanalysewerkzeug den undefinierten möglichen
Überlauf bei der Addition aufgrund des falschen Datentyps übersehen?
Integer Promotion!
> int8_t temp = a + b;
Wird temp wird auf int erweitert und damit macht der Code dann das, was
er (eigentlich) machen sollte.
Je nach Analyse Werkzeug bekommst du aber auch entsprechende Warnungen
angezeigt.
Walter Tarpan schrieb:> Aber wie kann ein Codeanalysewerkzeug den undefinierten möglichen> Überlauf bei der Addition aufgrund des falschen Datentyps übersehen?
Da kann nichts undefiniert überlaufen. a liegt von 0 bis 255, b
liegt von -128 bis 127. Durch die integer promotion ist sowohl das
minimale Ergebnis -128 als auch das maximale von 382 als "int"
darstellbar, es ist also erstmal nichts undefiniert daran (allerdings
durch die truncation u. U. nicht das, was du erwartet hättest).
Allerdings bekomme ich beim clang dafür schon eine Warnung, wenngleich
in der nächsten Zeile:
1
foo.c:6:15: warning: comparison of constant 255 with expression of type 'int8_t' (aka 'signed char') is always false
Hallo Jörg,
danke für die Erläuterungen. Jetzt verstehe ich auch den Hintergrund,
warum ich nicht gewarnt werde: Durch die Integer Promotion ist fast jede
Zuweisung an einen kleinen Integer-Typen eine Trunkierung, und bei
-Wconversion bekomme ich damit für so ziemlich für jede Zeile mit einer
(u)int(8/16)_t -Zuweisung eine Warnung. *)
Ich bin mal gespannt, wann ich mich an die C-Integer-Regeln gewöhne.
Edit:
*) Ich sehe gerade, daß -Wconversion eigentlich für einen ganz anderen
Zweck gedacht ist
Walter Tarpan schrieb:> Polyspace scheint im oberen Preissegment angesiedelt zu sein.
Ja das ist es. Wir hattens in der Firma, die Kosten lagen im
fünfstelligen Bereich (exakte Lizenz und Zahl kenn ich nicht).
Allerdings natürlich eine sehr mächtige Software, wir habens verwendet
um Software für Raumfahrt zu analysieren.
Walter Tarpan schrieb:> Ich bin mal gespannt, wann ich mich an die C-Integer-Regeln gewöhne.
Ich empfehle dir, auch mal MISRA-C anzusehen. Dort gibt es sehr gute
Beispiele wie man es macht oder auch eben NICHT macht. Da kommen genau
solche Punkte drin vor.
ein_ingenieur schrieb:> Ich empfehle dir, auch mal MISRA-C anzusehen. Dort gibt es sehr gute> Beispiele wie man es macht oder auch eben NICHT macht. Da kommen genau> solche Punkte drin vor.
Wobei MISRA meiner bescheidenen Meinung nach auch nicht das Gelbe vom Ei
ist. Sicher macht es die Software "sicherer", aber nicht unbedingt auch
immer leserlicher, vor allem wenn es um Pointer vs. Arrays geht :-/
Und dann gibt es noch die zahlreiche Codeschnipsel wo man sich
entscheiden muss, ob der Compiler oder der MISRA Checker meckern darf,
aber keine Lösung existiert womit beide zufrieden sind.
Hat jemand mal Flexelint (die "gratis" Version von PC-Lint) probiert?
(http://www.gimpel.com/html/flex.htm)
Eric B. schrieb:> (die "gratis" Version von PC-Lint
A one user, non-floating license for one computer workstation is $998
Ich finde da nichts von kostenlos.
900ss D. schrieb:> Eric B. schrieb:>> (die "gratis" Version von PC-Lint>> A one user, non-floating license for one computer workstation is $998>> Ich finde da nichts von kostenlos.
Oh, hast du Recht. :-/ Ich hatte in Errinnerung, dass Flexelint die
Evaluierungsversion war von PC-Lint und habe nicht weitergelesen.
Gimpel bietet offensichtlich keine Evaluierungsversionen an...