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
1
# 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'
1
// Gnu C/C++ (version 2.95.3 or later), -si4 -sp4, lib-gtk.lnt
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.
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.
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.
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
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
1
typedefunsignedintuint16_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?
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?
Ε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.
1
#define __attribute__() ()
Das und ähnliche Versuche schlugen fehl. Lint versteht es nicht.
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.
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.
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
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.
