Auf die Gefahr hin darauf hingewiesen zu werden zu Googeln, beginne ich
doch diesen Thread um Leuten wie mir Lint etwas näher zu bringen.
Prinzipiell bin ich auf Lint gestoßen, da mein Programm immer öfter bei
den ungewöhnlichsten Situationen "abstürzt" ist. Nun möchte ich Lint
nutzen um damit (wahrscheinlich einige) Bugs aus meinem Code zu
verbannen.
Leider ist mir noch nicht ganz klar wie Lint benutzt werden kann und zum
Probieren fehlt mir im Moment noch der Zugriff auf den Rechner mit der
FlexLint Lizenz.
Also daher würde mich interessieren wie ich Lint als
Kommandozeilenprogramm bedienen kann.
Als erst war mir klar, dass ich meine Libs und eigenen Headerfiles
einbinden muss. Das sieht glaube ich so aus: -i"/lib /hanswurst"
Nun bin ich im Handbuch auf das Kapitel "Compiler Adaption" gestoßen.
Bei FlexLint werden schon einige *.lnt Files angeboten z.B. für Borland
5.0 etc. Muss ich hier etwas beachten oder reicht die Datei für "Generic
Compilers"?
Außerdem ist mir noch nicht ganz klar welche Dateien ich im
Programmaufruf mit angeben muss. Reicht hier die main.c?
Welche Optionen für Lint bzw. dessen Fehlermeldungen benutzt/empfielt
ihr?
> Als erst war mir klar, dass ich meine Libs und eigenen Headerfiles> einbinden muss.
Deine Libraries interessieren Lint nicht, denn das arbeitet nur auf
Sourcecodeebene.
Du solltest alle benutzten *.c und *.h angeben.
Mit *.lib, *.a oder *.o kann Lint wie gesagt nichts anfangen.
Achso.
Für Files wie stdio.h ist die Option " -i"/lib /hanswurst" " aber schon
wichtig, oder? Ansonsten müßte ich ja alle "standart"-Headerfiles extra
mit Pfad angeben.
Hat jemand einen Tipp zu "Compiler Adaption", oder ist das hier wirklich
egal?
> Für Files wie stdio.h ist die Option " -i"/lib /hanswurst" " aber schon> wichtig, oder?
Ja. Nur liegen die nicht in /lib, sondern in /inc oder /include.
> Ansonsten müßte ich ja alle "standart"-Headerfiles extra> mit Pfad angeben.
Das will man auch bei Standard -Headerfiles nicht.
Ein Stacktest im Programm wäre da wohl hilfreicher.
Wenn der Compiler die entsprechende Option bietet, einschalten.
Bei einem Controller den gesamten verfügbaren RAM bei der
Initialisierung mit einem 'magic value' beschreiben und im Programm
später testen was davon noch übrig ist.
madler wrote:
> Ansonsten gibts auch noch Valgrind (sofern Du Linux benutzen> kannst/willst)> http://valgrind.org/
In der Doku dazu steht "It works directly with existing executables".
Wie kann ich das Tool für c-Files nutzen?
Mir ist jetzt absolut nicht klar, was ein Stacktest bzw. Valgrind
mit Lint zu tun haben soll.
Lint überprüft den Code statisch auf oft gemacht und
beliebte Fehler bzw. Dinge die so vom Standard her nicht gedeckt
sind.
Valgrind überprüft zur Laufzeit, ob die Speicherzugriffe des
Programms koscher sind.
Das eine hat mit dem anderen nicht das Geringste zu tun.
> Mir ist jetzt absolut nicht klar, was ein Stacktest bzw. Valgrind> mit Lint zu tun haben soll.
Nichts, aber mir ist Valgrind auch in den Sinn gekommen, als ich das
Ursprungsposting gelesen hab. Schließlich ist dort davon die Rede, daß
das "Programm immer öfter bei den ungewöhnlichsten
Situationen abstürzt ist", und gerade solche Fehler sind oft ein Fall
für einen Memory-Debugger.
Also ich benutze jetzt mal zum testen "Splint", da es bereits
vorkompiliert in den Ubuntu Packetquellen vorhanden war.
Ich habe aus dem Winavr Ordner auf meinem Rechner die Ordner
"avr/include" und "lib/gcc/avr/4.2.2/include" in einen Ordner "lib"
zusammenkopiert. Damit sollte ich alle nötigen Headerfiles erwischt
haben, die für mein Programm nötig sind.
Als nächstes führe ich Splint aus mit:
splint -I"/media/disk/statische Codeanalyse/lib" main.c
Leider bekomme ich Unmengen an Meldungen. Hier ein Beispiel:
1
../../statische Codeanalyse/lib/stdint.h:121:20:
2
Datatype int8_t declared with inconsistent type: int
3
A function, variable or constant is redefined with a different type. (Use
4
-incondefs to inhibit warning)
5
load file standard.lcd: Specification of int8_t: arbitrary integral type
Anscheinend habe ich doch nicht die richtigen Libaries eingebunden, oder
irgendwas fehlt?!
Kennt sich damit jemand aus?
> Ich habe aus dem Winavr Ordner auf meinem Rechner die Ordner> "avr/include" und "lib/gcc/avr/4.2.2/include" in einen Ordner "lib"> zusammenkopiert.
Lass mal die Kopiererei sein, und gib die Include-Pfade direkt (mit
zwei -I-Optionen) an.
Splint scheint bestimmte Header-Files (darunter stdint.h) gar nicht
einzulesen, sondern statt dessen die Splint-eigenen Deklarationen in
standard.lcd zu verwenden. Wenn nun stdint.h woanders hinkopiert wird,
denkt Splint wohl, es handle sich um ein vom Benutzer selbst
geschriebenes Header-File, das nur zufälligerweise den gleichen Namen
trägt, und bindet es deswegen zusätzlich zu standard.lcd ein, was zum
Konflikt führt.
Mich wundert zwar es ein wenig, woher Splint weiß, welches das
ursprüngliche Verzeichnis der Standard-Header-Files ist, aber auch
dafür gibt es sicher eine Erklärung.
Ok. Ich hab jetzt die beiden Verzeichnisse mit zwei -I"..." angegeben.
Leider noch der gleiche Fehler.
PS: bei stddef.h mußte ich alle '\' entfernen, damit splint keinen
fehler bringt.
> Ok. Ich hab jetzt die beiden Verzeichnisse mit zwei -I"..."> angegeben.
Ja, so war das auch gemeint.
> Leider noch der gleiche Fehler.
Du schreibst weiter oben:
> Also ich benutze jetzt mal zum testen "Splint", da es bereits> vorkompiliert in den Ubuntu Packetquellen vorhanden war.>> Ich habe aus dem Winavr Ordner auf meinem Rechner die Ordner ...
Arbeitest du unter Windows oder Linux? Oder benutzt du unter Linux die
AVR-Header-Files auf einer gemounteten Windows-Partition, weil du
unter Linux keine AVR-Libc installiert hast?
Sollte dies der Fall sein, müsste man noch einmal genauer nachschauen,
wann Splint das stdint.h als Standard-Header-File ansieht und es
deswegen überspringt. In deinem Fall sieht er es offensichtlich als
selbstgeschrieben an und überspringt es nicht, was zum Konflikt mit
standard.lcd führt.
> bei stddef.h mußte ich alle '\' entfernen, damit splint keinen> fehler bringt.
Welche '\' meinst du? Die Fortsetzungszeichen am Zeilenende im
Quellcode, z.B. bei den Makrodefinitionen? Wenn ja, solltest du
vielleicht die Dateien alle vom DOS-Format ins Unix-Format
konvertieren, damit die CR/LFs durch LFs ersetzt werden. Sonst ist aus
Unix/Linux-Sicht das '\' evtl. nicht das letzte Zeichen in der Zeile.
Meinem Splint ist das zwar egal, aber vielleicht hast du eine andere
Version, bei der das nicht so ist.
Hi,
Danke schon mal für die Antwort.
Ich nutze Ubuntu auf meinem Arbeitsrechner, wobei ich immer noch in
einem VMWare Windows meinen Code schreibe und kompiliere.
Mit dem '\' meine ich wirklich das Fortsetzungszeichen. Wobei das nur in
der stddef.h zu Fehlern führt. Sonst ist es anscheinend nirgends
benutzt.
Aber zurück zum eigentlichen Problem. Mit -nolib habe ich das "Problem"
"beseitigt". Hoffe ich. Es gibt auf jeden Fall keine Meldungen mehr
dazu.
Jetzt gibts die Meldung:
Also jetzt nutze ich Splint auf Windows. Keine Besserung
Ich habe alle Dateien schön zusammengetragen und mittels -I eingebunden.
Dann bekomme ich diese Fehlermeldung:
josefk(_nologin?) wrote:
> da. Was mir aber auch nicht weiter hilft. Tja. Ich habe mir das schöner> vorgestellt.
Das Problem ist, dass du da das Tool über Systemcode drüberjagst.
Der ist aber naturgemäß sowieso meist mit irgendwelchen Gemeinheiten
und Besonderheiten gespickt, die allesamt compilerabhängig sind.
Ich würde mich darauf konzentrieren, dass du dem Lint Tool die
Systemheader entweder vorenthalten kannst, oder in einer speziellen
Version unterjubelst, die komplett entschärft sind und praktisch
nur noch die Funktionsprotoypen enthalten.
Die originalen Systemheader da durchzujagen wird wahrscheinlich
sowieso sinnlos sein, weil da Lint an allen Ecken und Enden
schreien wird. Und ausserdem interessiert dich ja sowieso nicht,
welche Schweinereien Lint da in den Systemheadern entdeckt.
Beitrag "Re: statische Codeanalyse - Wie macht Ihr das?"
Erfahrungsgemäß ist das Arbeiten mit Lint ziemlich aufwendig, da der das
Gras wachsen hört und man dann erst mal nachsehen muß, was an den
Meldungen wirklich dran ist.
So nach dem Motto Wasch mir den Pelz , aber mach mich nicht naß
funktioniert das leider nicht.
Hallo,
auch wenn der Beitrag schon etwas älter ist, antworte ich mal, ist imo
ein interessantes Thema.
Als erstes, vielleicht mal die Anleitung lesen? =)
Die Fehler "Word after a stylized comment marker does not correspond to
a stylized
comment." kommen normalerweise daher, dass du irgendwo nen Kommentar
der Form /*@... hast und in Splint wird mit /*@ eine Annotation
eingefügt aber in deinem Code kommt nach dem @ anscheinend keine gültige
Splint Annotation.
Als nächstes muss man darauf achten, dass Splint nur ANSI-C versteht,
d.h. Compilerspezifische Dinge versteht Splint nicht. Ein häufiger
Fehler wird z.B. durch ein '@' im Code verursacht. Falls sowas vorkommt
sollte man das durch ein #define umgehen.
1
#ifndef __SPLINT__
2
#define _NEAR @near
3
#else
4
#define _NEAR
5
#endif
Das define _SPLINT_ kann man Splint in der Kommandozeile so mit auf
den Weg geben: -D__SPLINT__
Warnungen einfach ausschalten ist übrigens meist der falsche Weg, man
sollte verstehen woher sie kommen und dann den Code entsprechend
anpassen.
Die standard librarys brauchst du nicht extra einbinden, die sind bei
Splint in standard.lcd schon drin und werden automatisch geladen.
Christian H. schrieb:> Allerdings ist dann nicht klar ob Splint diese Funktion als Interrupt> nutzt, der Sinn von __irq verloren geht.
Das tut er mit Sicherheit.
__irq ist kein Standard C Schlüsselwort und Splint wird nichts von
Interrupts wissen, weil es die in Standard C ebenfalls nicht gibt.
Nochmal:
Splint, wie alle Lint, überprüft dein Programm auf Quelltextebene.
Es sieht sich sozusagen an, ob
"Das Messer speist mit dem U-Boot."
den (verschärften) syntaktischen Regeln der deutschen Sprache genügt.
Ein deutscher Satz sei etwas das nach der Regel aufgebaut ist
Subjekt Verb Objekt
"Das Messer" ist das Subjekt. Passt
Der Artikel zu Messer muss "das" lauten. Passt ebenfalls
"speist" ist das Verb
Das Subjekt steht in der 3. Person Singular. Also muss das Verb
entsprechend konjugiert sein. 3. Person Singular von "speisen"
lautet im Präsens "speist". Passt
"mit dem U-Boot" ist das Objekt
.. ich spar mir jetzt die Regeln. Du weißt wie es weitergeht.
Das ist das was Lint macht. Es sieht sich, schärfer als der Compiler,
an, ob du die Regeln eingehalten hast. Und es sieht sich auch beliebte
Fehler an, ob du sie gemacht hast, wie zb ein = anstelle eines == in
einer If-Bedingung und viele anderen Sachen.
Was Lint nicht tut: Es überprüft nicht, ob deine Logik stimmt.
Obiger Satz erfüllt perfekt alle Regeln der deutschen Sprache. Trotzdem
ist er Unsinn.
Daher ist es für Lint auch völlig egal, ob diese Funktion eine Interrupt
Funktion ist, oder nicht. Für Lint ist das ganz einfach eine Funktion.
Oder sollte es zumindest sein. D.h. an dieser Stelle versteckt man die
vom Compiler erzwungene C-Erweiterung, so dass sie Lint nie zu Gesicht
bekommt.
Wenn man sich allerdings erwartet, dass einem Lint die logischen Fehler
in einem Programm sucht, dann hat man mit Zitronen gehandelt.