Hallo zusammen,

nachdem immer wieder erwähnt wird, dass statische Codeanalyse sehr
wichtig sein soll, habe ich mich auch mal daran gewagt. Leider ohne
Erfolg. Ich Nutze Splint auf einem Windowsrechner und hab eigetlich
keine Ahnung wie ich das Ganze nutzen soll.
Ich habe zu dem Thema schon einmal einen Beitrag geschrieben, der mich
aber nicht wirklich weiter gebracht hat.
Daher möchte ich euch mal fragen, ob und wie ihr Splint nutzt. Was macht
ihr um alle Libs einzubinden, welche Flags setzt ihr etc?

Würde mich schon sehr interessieren wie das geht!

Also ich bin auf diesen Beitrag in einem anderen Forum gestoßen:
http://www.avrfreaks.net/index.php?name=PNphpBB2&a...
Das hat mir schon mal weiter geholfen. Trotzdem bekomme ich immer wieder
den Fehler:

C:\lib\stdarg.h(43,41):
No tyoe before declaration name (implicit int type): __builtin_va_list:
int
A variable declaration has no explicit type. The type is implicitly int.

Das kann man ja noch ignorieren lassen, aber folgendes nicht mehr:

C:\lib\stdarg.h(43,41): Parse Error:
Suspect missing struct or union keyword: __builtin_va_list: int

Was bedeutet das. Das die stdarg.h Fehler beinhaltet glaube ich nicht,
das muss wohl irgendwo an mir liegen?!

Josef Kaeufl wrote:

> Was bedeutet das. Das die stdarg.h Fehler beinhaltet glaube ich nicht,
> das muss wohl irgendwo an mir liegen?!

Diese Art von Fehlermeldungen von Lint sind nur Hinweise darauf, daß
C/C++ an dieser Stelle etwas gegen den Strich gebürstet wird. Meistens
sind die angemeckerten Konstrukte auch schon uralt und bewährt,
entsprechen aber nicht mehr den heutigen Regeln.

Wenn du solche Fehler aus Standard-Bibliotheken bekommst, kannst du sie
getrost ignorieren. Wünschenswert wäre allerdings, das durch die
entsprechenden Tolerierungsoptionen in Spezialkommentaren am Ort der
Fehlermeldung zu unterdrücken, oder ganze Headerfiles von der Prüfung
auszunehmen.

Das kann wohl sein. Aber wie schon woanders erwähnt (
Beitrag "Wie benutzt man Lint?!" ) habe ich keine Ahnung was
ich nun machen muss.

Wenn ich meinen Code einfach so, ohne irgendwelche includes, prüfen
lasse, dann wird mir wahrscheinlich splint nicht mehr über die stdarg.h
etc. drüber bügel, aber woher weiß splint dann was z.B. ein uint8_t ist?
Ich habe oft definitionen aus der stdint.h benutzt um möglichst lange
keine Probleme mit späteren Versionen der Winavr zu haben (ob das im
Endeffekt was bringt weiß ich nicht. mir wurde das nur irgendwann
geraten).
Woher weißt dann Splint was Port in Pin ist? Muss ich das alles dann
auskommentieren?

Ahh. Hab gerade gesehen dass du schon auf diesen Beitrag verlinkt hast
:)

Josef Kaeufl wrote:
> Das kann wohl sein. Aber wie schon woanders erwähnt (
> Beitrag "Wie benutzt man Lint?!" ) habe ich keine Ahnung was
> ich nun machen muss.

Als erstes die Grundregel: Handbücher lesen

Dort sind - zumindest bei PC-Lint, mit dem ich schon viel gearbeitet
habe - massen von Optionen beschrieben, mit denen man die Generierung
von Fehlermeldungen global und lokal steuern kann.

Zudem ist es gut, nach Grundeinstellungen (für Lint) für den Compiler zu
suchen, mit dem die Quelltexte bearbeitet werden. Da sind dann schon mal
die immer wiederkehrenden blinden Alarme ausgeblendet.

Dann muß man sich durchs erste Fehlerlisting beißen und prüfen, welche
Fehler toleriert werden sollen; die entschärft man dann zunächst lokal.
Sollten sie sich quer durchs ganze Projekt ziehen, übernimmt man die
entsprechende Sperre in die globalen Einstellungen.

Die ersten paar Module sind Knochenarbeit. Wenn man dann die
Pappenheimer kennt und das projektspezifische Rauschen global
unterdrückt ist, geht es schneller.

Sonntagsspaziergang ist es aber auf jeden Fall keiner...

> Wenn ich meinen Code einfach so, ohne irgendwelche includes, prüfen
> lasse, dann wird mir wahrscheinlich splint nicht mehr über die stdarg.h
> etc. drüber bügel, aber woher weiß splint dann was z.B. ein uint8_t ist?

Die Header müssen selbstverständlich mit durch Lint gehen - sonst kennt
der ja die Definitionen nicht und überschüttet dich mit einem ganzen
Erdrutsch von Meldungen.

Such nach einer Option, mit der man einen include-File aus der
Fehleranalyse ausnehmen kann. Dann hats Ruhe.

> Ich habe oft definitionen aus der stdint.h benutzt um möglichst lange
> keine Probleme mit späteren Versionen der Winavr zu haben (ob das im
> Endeffekt was bringt weiß ich nicht. mir wurde das nur irgendwann
> geraten).
> Woher weißt dann Splint was Port in Pin ist? Muss ich das alles dann
> auskommentieren?

Du mußt nichts auskommentieren - du must die lintspezifischen Optionen
in spezielle Kommentare eingeschlossen in den Quelltext schreiben.

Für Headerfiles müßte es eine Option geben, über die man einen ganzen
.h-File von der Fehlergenerierung ausnehmen kann.

Lies mal hier: http://splint.org/manual/html/sec14.html

Puhh. Danke schon mal für die ausführliche Antwort. Ich habs aber immer
noch nicht auf die Reihe bekommen also schreib ich mal was ich gemacht
habe. Da wird mir meistens selber erst bewußt wo der Fehler liegt. Also:

Flags, die ich nutze:
-D um __GNUC__=3 zu setzten (warum weiß ich nicht)
      __GNUC_MINOR__=3 zu setzten (warum weiß ich nicht)
      _AVR_AT90CAN128_ zu setzten

-I um meine Libs, die auch gefunden werden, anzugeben
-exportlocal um Deklarationen außerhalb der Module sichtbar (?!) zu
machen
-incondefs um keine Ahnung, hab ich so gefunden als Beispiel
+gnuextensions naja, Gnu hald
+charindex "Allow char to index arrays."
-predboolint "Type of condition test is an integral type."
-posixlib "Use the POSIX standard library." Hier bin ich mir nicht
wirklich sicher
+nolib verhindert hoffentlich, dass die Standartlibary geladen wird.


Zusätzlich habe ich versucht mit /*@ignore@*/ CODE /*@end@*/ den
enthaltenen CODE nicht prüfen zu lassen. Was aber doch geschieht. Nur
Fehlermeldungen werden unterdrückt. Hab sogar alle #include <..> damit
"auskommentiert".

Fehlermeldungen bekomme ich immer nocht: in der interrupt.h is was krumm
und in der stdarg.h auch.


Wie kann ich nur splint dazu bringen die ganzen libs nicht auf Fehler zu
testen? Ich finde dazu einfach nichts.

OK, ich hab jetzt mal viele Prototypen gemacht. Jetzt läufts. Krass was
Splint alles findet. Ich fange wohl besser erst mal mit einem weak check
an ;)

Tja, ohne Augen gehts eben manchmal doch besser...

Wenn man die erste große Hürde überwunden hat, hält sich der
Pflegeaufwand für ein kontinuierlich entwickeltes Projekt erfreulich in
Grenzen. Man muß den Lint eben nur regelmäßig laufen lassen.

Puhh. Beim nächsten mal werde ich das Tool sicher von Anfang an nutzen.
Das würde doppelt Zeit sparen....

Hier noch zwei nette Artikel dazu:

http://www.linux-magazin.de/heft_abo/ausgaben/2003...

http://www.linux-magazin.de/heft_abo/ausgaben/2003...

Hi,

@ Josef Kaeufl
> Puhh. Beim nächsten mal werde ich das Tool sicher von Anfang an nutzen.
> Das würde doppelt Zeit sparen....

Das ist eine sehr gute Idee ... im Ernst! Mal abgesehen davon, das ein
Lint tatsächlich und gerade auch bei der C-Programmierung (gibt ja
genügend Möglichkeiten für Fehler ...) hilft. Auch und vor allem das
"von Anfang an" ist essentiell! Denn in einem gewachsenen Projekt, das
vorher noch keinen Lint gesehen hat, ist es manchmal schwer bis
unmöglich, das Ganze meldungsfrei zu bekommen, ohne Teile komplett neu
zu programmieren (mit allen Problemen - neue Fehler etc.)

Und btw. auch so ein splint hat seine Tücken und manchmal nervt er auch
einfach. Ich habe schon Projekte gesehen, die zum einen die C-Compiler
(die ja auch selbst einige Features in dieser Richtung haben!) komplett
"scharfschalten" UND gleich mehrere verschiedene Lint-Produkte
GLEICHZEITIG einsetzen! (einfach weil verschiedene Lint verschiedene
Meldungen bringen, jedes Produkt hat seine Schwächen und Stärken!) C ist
halt nix für Weicheier! ;-))

Schönen Tag noch,
Thomas

Was bedeutet eigentlich: _GNUC_MINOR_ ?
Bzw. was genau legt man damit für den Compiler fest?