Hallo, ich möchte meinen Code mit Splint überprüfen.
Dazu habe ich unter Ubuntu per sudo apt-get install splint das Ganze mal
installiert.
Per Aufruf "splint main.c" sagt er mir, das er die eingebundene
bcm2835.h nicht findet. Soweit logisch,isch hab ihm ja noch nicht
verraten wo die liegt.
Die bcm2835.c und .h liegen in einem Ordner auf dem Desktop, den ich
testweise per Parameter "-I Desktop/..." hinzufüge.
Er meckert weiterhin rum, das er im header irgendwo den Posixstandart
braucht und schlägt vor, "+posixlib" anzufügen.
Parse Error. (For help on parse errors, see splint -help parseerrors.)
12
*** Cannot continue.
Ist jetzt das Ergebnis.
Die Fehlermeldungen sind soweit plausibel, da ich dort noch
1
#warning
drinne habe. Auch die Kommentarwarnungen sind in Ordnung und werden
später beseitigt.
Allerdings bringt er in der Headerdatei Fehler und kann anscheinend
deswegen nicht weitermachen. Wie vermeide ich, dass andere Dateien außer
meine main.c geprüft werden?
Oder sagt mir das, dass meine main.c frei von Fehlern ist (was ich nicht
glaube bei 1000 Zeilen)?
Es sagt dir, daß schon in den allerersten Zeilen so viele Fehler sind,
daß er danach nicht weitermachen kann. Deine main.c hate r noch gar
nicht angesehen.
Und nein, du kannst deine main.c nicht ohne die dafür benötigten header
compilieren.
Oliver
Gar nicht.
Wenn das fertige header sind, solltest du herausfinden, warum sprint die
nicht will.
Wobei die Fehlermeldungen vermuten lassen, daß die Fehler doch in deinem
Code stecken. Was steht denn da in Zeile 271?
Oliver
Es ist normal, dass Du Lint (mit welchem Geschmack auch immer) für den
Codecheck beim ersten Mal in grösserem Umfang durch Optionen und
Hilfsdateien auf den Quellcode anpassen musst.
Ursächlich hat das mit dem Compiler und den Libraries zu tun.
Da musst Du Schritt für Schritt durch. Nur Mut. Es ist zu schaffen.
Ein gerütteltes Maß an Programmiererfahrung auch mit verschiedenen APIs
und Libraries und doch auch einige Englischkenntnisse sind notwendig.
Ich habe da einen Kommentar // der mit dem Zeichen * beginnt. Somit
macht er ein /* daraus. Ich habe schon Leerzeichen eingefügt.
Jetzt sind die Fehler wie erwartet weg, aber mehr auch nicht.
Ich hatte Testweise mal alle Librarys auskommentiert und dann nach einem
Durchlauf wieder eingefügt.
Ich nutze:
1
#include<stdio.h>
2
#include<stdlib.h>
3
#include<bcm2835.h>
4
#include<fcntl.h>
5
#include<unistd.h>
6
#include<math.h>
Jetzt meckert er nicht mehr bei der bcm2835.h, sondern bei der fcntl.h
Ach ja, dass:
>Hm und wie prüfe ich meinen Quellcode nun, ohne auf Fehler in>eingebundenen Dateien einzugehen?
geht schon prinzipiell nicht, es sei denn man bräuchte in dem Projekt
keine H-Dateien.
In H-Dateien sind sowohl Deklarationen als auch Preprozessor-Anweisungen
enthalten die in der Regel notwendig sind, main zu übersetzen. Also muss
zuer Lint-Prüfung das H-File auch verstanden sein.
Du solltest wirklich mal die Anweisungen zu Splint lesen. Das sind
absolut typische Probleme. Und mit ein bisschen Englisch kommt man sogar
drauf was für welche. Du willst doch jetzt nicht hier sämtliche
Lint-Meldungen von uns in Anweisungen zur Korrektur umwandeln lassen,
oder?
Hmm schrieb:>>Ich hatte Testweise mal alle Librarys auskommentiert> Nein. Hattest Du nicht. Du hast die Include-Anweisungen auskommentiert.
Stimmt, aber ich versteh die Reaktion von Splint darauf trotzdem nicht?
Irgendwie muss ich doch meinen Quellcode trotzdem prüfen können?
>Stimmt, aber ich versteh die Reaktion von Splint darauf trotzdem nicht?>Irgendwie muss ich doch meinen Quellcode trotzdem prüfen können?
Du verkennst die Situation: Das was Dich, aus Deiner Sicht daran
hindert, den Code zu prüfen ist genau das Ergebnis der Prüfung. Lint
meldet Dir Probleme mit Deinem Quellcode. Die musst Du beseitigen. Dafür
benutzt Du ja Lint.
Zugegeben, etwas tiefer geschaut, sind das Anpassungen an Lint, das
schrieb ich ja schon oben. Die musst Du nun erstmal erledigen. Daran
führt kein Weg vorbei. Das schrieb ich auch schon oben. Also: Mach Dir
ran.
Dann kommen wir dann doch mal zu der eigentlich interessanten Frage:
WARUM ?
Den, ganz ehrlich, deine Fragen und auch dein Vorgehen deuten nicht
darauf hin, daß du mit dem Ergebnis eines irgendwann einmal
erfolgreichen sprint-Laufes viel anfangen könntest.
Aktuelle C-Compiler sind inzwischen in der Lage, die allermeisten
Nickligkeiten im Code selber zu entdecken. Du musst halt den
Warnungslevel ensprechend einstellen, dann meckert dir der Compiler
schon alles fragwürdige an.
Was also versprichst du dir von sprint ?
Oliver
Ich verspreche mir davon, Schussligkeitsfehler wie zum Beispiel nicht
initialisierte Variablen zu melden die der Compiler aber nicht
anmeckert.
Ich werde mir die Compileroptionen nochmal anschauen.
Aber ist es nicht trotzdem verwunderlich, dass bei etablierten librarys
Fehler angezeigt werden?
>Aber ist es nicht trotzdem verwunderlich, dass bei etablierten librarys>Fehler angezeigt werden?
Nun, es gibt ja nicht nur eine etablierte Library sondern mehrere.
Dabei meine ich nicht das Widersprüche oder sagen wir "Reibungen"
zwischen einer libusb und einer math auftreten sondern zwischen libusb
und libusb und math und math. Verschiedene Posix-Stände, BSD, C99, ANSI,
etc., was weiss ich... etcpp.
Das kann man hier nur andeuten; ist ein umfängliches Thema. Deswegen ja
die Frage nach Deiner Erfahrung, die Du leider nicht beantwortet hast.
>Ich verspreche mir davon, Schussligkeitsfehler wie zum Beispiel nicht>initialisierte Variablen zu melden die der Compiler aber nicht>anmeckert.
Was ist denn das für ein Compiler? Gab's den ab einem Liter tanken dazu?
:-) Besorg Dir nen anständigen Compiler. gnuc z.B.
Nimm mir den rauhen Ton nicht allzu übel. Du hast da, Deinem
Kenntnisstand nach, leider in ein Nest von Wespen gestossen, denen Du
nicht gewachsen bist.
Stelle einfach alle Warnings an. Das sollte für den Hausgebrauch
reichen.
>Naja erweiterte Grundlagen würde ich behaupten.
Also K&R, 2. Auflage (ANSI) bis Seite 50 oder 90? Oder was?
Falls das zutrifft, bist Du weit von dem Punkt entfernt wo Du Lint
sinnvoll verwendest. Allermindesten noch ein Jahr würde ich sagen. In
der Regel lernst Du erst die Techniken und die möglichen Fehler.
Lint ist eher was für die Leute die alle die blöden Fehler schonmal
gemacht und selbst gefunden haben und in einem 20-Module-Projekt nach
der x-ten Wiederholung davon suchen.
Ach schon bis 185, aber nach hinten zu mit immer größeren Lücken. Je
nachdem was ich schonmal gebraucht habe wurde halt nachgeguckt.
Zudem ist alles ein bisschen eingerostet.
Danke trotzdem für die Hilfe:)
