PC-Lint und interrupt.h

[Alu (Gast)]

Moin zusammen,

lasse ich PC-Lint über mein AVR GCC Projekt laufen, erhalte ich als 
ersten Fehler folgenden:

#  define ISR(vector, [attributes])
C:\Progra~1\Atmel\AVRSTU~1.0\AVRTOO~1\avr\include\avr\interrupt.h  131  Error
    10: Expecting ')'

Die 'interrupt.h' gehört zu WinAVR, bzw. beim AVR Studio 5 zur 
Toolchain. Ich habe die Datei nicht modifiziert. In der angemoserten 
Zeile der 'interrupt.h' steht

#  define ISR(vector, [attributes])

Hat jemand eine Idee, warum Lint das nicht mag, bzw. was ich anders 
machen muss? Oder hat mal jemand eine angepasste Konfigdatei für Lint 
zur Verwendung mit AVR parat?


Danke euch!



Weitere Infos:

Inhalt der PC-Lint-Konfigdatei 'std.lnt'

//  Gnu C/C++ (version 2.95.3 or later), -si4 -sp4, lib-gtk.lnt
//  Standard lint options

-e835
au-misra2.lnt
co-gcc.lnt
options.lnt -si2 -sp2
-d__AVR_ATmega1284P__
-d__DOXYGEN__
-i"C:\Progra~1\Atmel\AVRSTU~1.0\AVRTOO~1\avr\include"
-i"C:\Progra~1\Atmel\AVRSTU~1.0\AVRTOO~1\avr\include\avr"
-i"C:\Progra~1\Atmel\AVRSTU~1.0\AVRTOO~1\avr\include\util"

Die Zeile "-d__DOXYGEN__" habe ich eingefügt, weil Lint sonst einen 
Fehler mit der stdio.h bekommt, da dort spezielle Compilerswitches für 
Lint unverständlich sind und in einer Fallunterscheidung auf Doxygen 
bereits die Anweisungen ohne Compilerschalter vorliegen.

[Εrnst B. (ernst)]

Alu schrieb:
> -d__DOXYGEN__

^^^^^
da ist höchstwarscheinlich der Fehler.

die libc-Header enthalten ungültiges C, das nur zur Dokumentation 
dient. Beim Compilieren wird das per #ifdef umgangen.
Der LINT sollte denselben Code zu sehen kriegen wie der Compiler, nicht 
wie das Dokumentations-Tool.

[Karl H. (kbuchegg)]

Alu schrieb:

> Die 'interrupt.h' gehört zu WinAVR

eben.
Das sind alles systemspezifisch angepasste Dinge. Mit Standard-C hat das 
alles nichts mehr zu tun.


> Hat jemand eine Idee, warum Lint das nicht mag, bzw. was ich anders
> machen muss?

Durchforste die Doku, ob es eine Möglichkeit gibt, dem PC-Lint klar zu 
machen, dass es bestimmte Dateien nicht untersuchen soll.
Alles was aus dem AVR-System kommt (also zb avr/io.h) schliesst du dabei 
aus.

[Alu (Gast)]

Danke schonmal. Mir war klar, dass das "-d__DOXYGEN__" den Fehler 
verursacht. Lasse ich es weg, hat Lint ein noch größeres Problem, da es 
in der 'stdint.h' z.B. die Zeile

typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));

nicht versteht und daraufhin alle möglichen Operationen mit diesem 
Datentyp bemängelt, weil angeblich mit vorzeichenbehafteten Integers 
gearbeitet wird.
Mit dem Doxygen-Schalter wird automatisch stattdessen die Zeile

typedef unsigned int uint16_t;

verarbeitet, die Lint versteht. Das sind dann ein paar Tausend Fehler 
weniger. ;)

Ich kann doch nun die Header-Dateien nicht ausklammern, sonst kann Lint 
doch mit meinem Source gar nichts mehr anfangen, oder? Auch solche 
define's wie TCNT0 usw. ergeben ohne die Header-Dateien keinen Sinn.

Wie macht ihr das?

[Εrnst B. (ernst)]

d.h. dein Grundproblem ist, dass dein LINT mit _attribute_ nix 
anfangen kann?

evtl. ein
#define __attribute__(x)
irgendwo hin, wo's nur der LINT sieht?

[Alu (Gast)]

Εrnst B✶ schrieb:
> d.h. dein Grundproblem ist, dass dein LINT mit attribute nix
> anfangen kann?

Ich weiß nicht, ob man es so ausdrücken kann. Es scheint ein Problem zu 
sein, aber mein Überblick reicht noch nicht aus, um festzustellen, ob es 
das grundsätzliche Problem ist oder nicht auch nur ein Folgefehler.

Die Idee mit dem Makro ist gar nicht schlecht. Allerdings bekomme ich es 
nicht hin.

#define __attribute__() ()

Das und ähnliche Versuche schlugen fehl. Lint versteht es nicht.

[Klaus W. (mfgkw)]

Alu schrieb:
> Die Idee mit dem Makro ist gar nicht schlecht. Allerdings bekomme ich es
> nicht hin.#define __attribute__() ()
> Das und ähnliche Versuche schlugen fehl. Lint versteht es nicht.

Das geht natürlich nicht; es steht doch oben schon richtig 
vorgeschlagen:

Εrnst B✶ schrieb:
> evtl. ein
> #define __attribute__(x)
> irgendwo hin, wo's nur der LINT sieht?

Wobei es wahrscheinlich geschickter ist, das bei den Lint-Optionen als 
Parameter zu definieren, und nicht mit #define im Quelltext.

[Alu (Gast)]

Deine Definition habe ich auch getestet. Sie funktioniert auch nicht. 
Dadurch wird

typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));

noch nicht zu

typedef unsigned int uint16_t;

PC-Lint meckert weiterhin über die angebliche Vermischung von 
vorzeichenbehafteten und vorzeichenlosen Größen.

Wenn ich das "__DOXYGEN__" drin lasse, dann die stdint.h einbinde und 
für die anderen Headers das "__DOXYGEN__" mit #undef wieder lösche, 
natürlich alles nur im Sichtbarkeitsbereich für PC-Lint, dann bin ich 
mein Problem umgangen. Allerdings ist das ziemlich dreckig und mögliche 
Folgeprobleme kann ich noch nicht absehen.

Hat denn noch niemand hier PC-Lint auf AVR-Basis verwendet? Kann ich mir 
fast nicht vorstellen.

[Karl H. (kbuchegg)]

Knifflig


> Hat denn noch niemand hier PC-Lint auf AVR-Basis verwendet? Kann ich mir
> fast nicht vorstellen.

Ich könnte mir vorstellen, dass es da mau aussieht. Die Programmgrößen 
um die es hier geht, sind ja noch gut zu überblicken und der 
überwiegende Anteil an Datentypen ist sowieso uint8_t


> PC-Lint meckert weiterhin über die angebliche Vermischung von
> vorzeichenbehafteten und vorzeichenlosen Größen.

Ich schätze mal er regt sich über solche Situationen auf

uint16_t i = 8;

   if( i == 128 )

i ist unsigned, 128 ist signed

[Alu (Gast)]

Karl Heinz Buchegger schrieb:
> Die Programmgrößen
> um die es hier geht, sind ja noch gut zu überblicken und der
> überwiegende Anteil an Datentypen ist sowieso uint8_t

Das Problem betrifft uint8_t genauso wie uint16_t. Beides ist auf 
gleiche Weise für PC-Lint unverständlich definiert (wegen 
Compilerkommandos, s.o.). Also auch bei meinen uint8_t-Daten gibt es das 
Problem, dass vorzeichenlose Werte für vorzeichenbehaftet gehalten 
werden, aber nur deshalb, weil PC-Lint die Typdefinition nicht versteht.

Karl Heinz Buchegger schrieb:
> Ich schätze mal er regt sich über solche Situationen auf
>
> uint16_t i = 8;
>
>    if( i == 128 )
>
> i ist unsigned, 128 ist signed

Nein nein, hier muss es natürlich 8U und 128U heißen. Aber Lint würde in 
diesem Beispiel dann meckern, weil er uint16_t für einen 
vorzeichenbehafteten Typ hält.

Nuja, ich habs ja umgangen und kann damit leben, aber schön ist es 
nicht.