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.

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

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:

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

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

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

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:

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

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

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.

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.

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.

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

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