Wie benutzt man Lint?!

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

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.

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.

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:

1

../../statische Codeanalyse/libaries/avr/include/stdint.h:137:4:

2

    Semantic comment unrecognized:  

3

  Word after a stylized comment marker does not correspond to a stylized

4

  comment. (Use -unrecogcomments to inhibit warning)

Und davon viele...

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

(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"

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

1

#ifndef __SPLINT__

2

void ISR_EINT_0_Handler (void) __irq; 

3

#endif

4

5

#ifdef __SPLINT__

6

void ISR_EINT_0_Handler (void); 

7

#endif

Oder optimiert:

1

#ifndef __SPLINT__

2

void ISR_EINT_0_Handler (void) __irq; 

3

#else

4

void ISR_EINT_0_Handler (void); 

5

#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

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.