Wie benutzt man Lint?!

[Josef K. (josefk)]

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?

[Rufus Τ. F. (rufus)]

> 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.

[Josef K. (josefk)]

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?

[Rufus Τ. F. (rufus)]

> 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.

[Ekschperde (Gast)]

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 (Gast)]

Ansonsten gibts auch noch Valgrind (sofern Du Linux benutzen 
kannst/willst)
http://valgrind.org/

[Josef K. (josefk)]

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?

[Karl H. (kbuchegg)]

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.

[Rolf Magnus (Gast)]

> 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.

[josefk (Gast)]

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:

../../statische Codeanalyse/lib/stdint.h:121:20:
    Datatype int8_t declared with inconsistent type: int
  A function, variable or constant is redefined with a different type. (Use
  -incondefs to inhibit warning)
   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?

[yalu (Gast)]

> 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.

[Josef K. (josefk)]

Wie kann ich 2 Argumente bei -I angeben? :)

[Josef K. (josefk)]

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.

[yalu (Gast)]

> 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.

[Josef K. (josefk)]

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:

../../statische Codeanalyse/libaries/avr/include/stdint.h:137:4:
    Semantic comment unrecognized:  
  Word after a stylized comment marker does not correspond to a stylized
  comment. (Use -unrecogcomments to inhibit warning)

Und davon viele...

[josefk(_nologin?) (Gast)]

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:

c:\prj\splint-3.1.1\bin>splint -I"C:\prj\libs\avr\include" -I"C:\prj\can_ethernet_conv
erter\libs\lib\gcc\avr\4.2.2\include" -I"C:\prj\libs\work" "C:\prj\uIP Listen 11 pure eth\main.c"
Splint 3.1.1 --- 12 April 2003

Standard library: H:\Programme\splint-3.1.1\lib\standard.lcd
   (created using Splint 3.018000)
C:\prj\libs\avr\include\avr\interrupt.h(126,23):
     Invalid character in macro parameter name
  Preprocessing error. (Use -preproc to inhibit warning)
   In file included from C:\prj\libs\work\system.h(93),
                 from C:\prj\uIP Listen 11 pure eth\global.h(8),
                 from C:\prj\uIP Listen 11 pure eth\main.c(2)
C:\prj\libs\avr\include\avr\interrupt.h(126,23):
     Parameter list for #define is not parseable
C:\prj\libs\avr\include\util\delay.h(90,98):
    #warning "Compiler optimizations disabled;
    functions from <util/delay.h> won't work as designed"
   In file included from C:\prj\uIP Listen 11 pure eth\main.c(7)
Preprocessing error for file: C:\prj\uIP Listen
    11 pure eth\main.c
*** Cannot continue.

Warum kommt das Tool nicht mal bis zu meinem eigenen Sourcecode?

Mich ärgert Lint immer mehr....

[josefk(_nologin?) (Gast)]

Jetzt hab ich mal alle interruptsaychen aus dem c-File entfernt und alle 
Warnings raus. Jetzt steht nur noch

c:\prj\can_ethernet_converter\gcc_work\splint-3.1.1\bin>splint -I"C:\prj\can_ethernet_converter\gcc_work\libs\avr\include" -I"C:\prj\can_ethernet_conv
erter\gcc_work\libs\lib\gcc\avr\4.2.2\include" -I"C:\prj\can_ethernet_converter\gcc_work\libs\work" "C:\prj\can_ethernet_converter\gcc_work\uIP Listen
 11 pure eth\main.c"

da. Was mir aber auch nicht weiter hilft. Tja. Ich habe mir das schöner 
vorgestellt.

[josefk(_nologin?) (Gast)]

Korrektur: Copy&Paste Fehler. ;)



Jetzt hab ich mal alle interruptsaychen aus dem c-File entfernt und alle
Warnings raus. Jetzt steht nur noch

C:\prj\libs\lib\gcc\avr\4.2.2\include\stdarg.h(4
    3,41): Parse Error: Suspect missing struct or union keyword:
    __builtin_va_list : int. (For help on parse errors, see splint -help
    parseerrors.)
*** Cannot continue.

da. Was mir aber auch nicht weiter hilft. Tja. Ich habe mir das schöner
vorgestellt.

[Karl H. (kbuchegg)]

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.

[Josef K. (josefk)]

Was genau meinst du damit? Soll ich die Module der WinAVR nicht 
einbinden? Woher weiß dann Lint z.B. was uint8_t sein soll?

[Uhu U. (uhu)]

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.

[chris (Gast)]

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.

#ifndef __SPLINT__
  #define _NEAR @near
#else
  #define _NEAR
#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. (blueicehaller)]

(Wie) Können Schlüsselwörter ignoriert werden?

Zitat übersetzt: __irq
Das __irq Schlüsselwort ermöglicht die C oder C++ Funktion als interrupt
routine zu nutzen.

__irq ist ein Funktionskennzeichner. Er beeinflusst den Typ/die Art der
Funktion.
Quelle: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0376c/BABICJBC.html

Multiposting: Beitrag "Re: Keil µVision Code-Checker"

[Christian H. (blueicehaller)]

Ich glaube ich habs jetzt verstanden.
Ich habe meine Header Datei wie folgt geändert:

#ifndef __SPLINT__
void ISR_EINT_0_Handler (void) __irq; 
#endif

#ifdef __SPLINT__
void ISR_EINT_0_Handler (void); 
#endif

Oder optimiert:

#ifndef __SPLINT__
void ISR_EINT_0_Handler (void) __irq; 
#else
void ISR_EINT_0_Handler (void); 
#endif

Allerdings ist dann nicht klar ob Splint diese Funktion als Interrupt 
nutzt, der Sinn von __irq verloren geht.
Möglicherweise gibt es alternative Anweisungen um Splint mitzuteilen 
diese Funktion als Interrupt zu nutzen ist.

http://www.cs.virginia.edu/pipermail/splint-discuss/2007-August/001023.html

[Karl H. (kbuchegg)]

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.