Hallo, ich versuche gerade FreeRTOS auf einem ARM7X256 zum laufen zubringen. Der Code funktioniert angeblich (Demo Code), aber ich habe da einige Fragen zu dem RTOS selber. Entweder ich kann kein C oder da wird getrickst und ich kenne den Trick nicht. In Queue.C steht : "typedef xQUEUE *XQueueHandle;" und im Header : "typedef void *XQueueHandle;" Mal abgesehen davon das jeder Code Checker da nur Fehler raus wirft, verstehe ich nicht wieso das überhaupt funktioniert. Kann mich jemand aufklären. Danke, Peter
ich bin mir grad nicht so sicher ob das hier das gleiche ist, aber man kann ja durchaus void - pointer definieren, um z.b. in anderen files keinen (wirklichen) zugriff auf die vom pointer referenzierten daten zu bekommen - quasi datenkapselung... just my few cents.
Hallo, das ist schon alles in Ordnung so! Einem Pointer vom Typ "void*" darf man jeden anderen Pointer zuweisen, die Typprüfung ist damit quasi ausser Kraft gesetzt, es muss nur ein Pointer sein. Einem Pointer vom Typ "xQUEUE*" dagegen nur einen vom Typ "xQUEUE*" Alles klar
Im Prinzip ja. ABER wenn ich den Code mir ansehe dann wird dort mit diesem Pointer gearbeitet. Läuft ja anscheinen auch, nur Debuggen möchte ich diese Stellen nie. Ansonsten verstehe ich nicht wieso man einen solchen Schrott in einem sonst so guten RTOS rein macht. Ich würde als mein Chef jeden Angestellten (Kollegen) der mir so etwas abliefert raus werfen. Alleine schon um alle Anderen zum vernünftigen Programmieren an zuleiten.
Ich würde sage das es bei C durchaus üblich ist und auch gut so. Es gibt sehr oft ein funktionen die dir ein void* als eine Art object zurückliefern. Und an die nächste Funktion übergibt du den zeiger wieder. Sie wollen aber verhindern das du auf die struktur zugreifst und eventuell daten veränderst. (in C++ würde man es mit private machen)
Das hat alles nichts mit schlampig, oder "vielleicht in C üblich" oder "anständigem Code" oder sonst was zu tun. Es gibt halt Funktionen an die man beliebige Datenstrukturen per Pointer übergeben kann und die definiert man dann als void*, weiter nichts!
Nun ja wenn ich was beliebiges weiter geben kann, dann ist das auch eine Unendlich große gefahren Quelle. Außerdem wenn ich nicht weiß was ich mal übergeben will dann sollte ich es lieber gleich lassen. Mir sind solche Sachen immer suspekt und es ist richtig so das da jeder Code Tester Fehler raus gibt. Das ist mal wieder etwas, was nie in C hätte erlaubt werden dürfen. Eine Schande das solche Tricks im FreeRTOS drin sind. Ich hoffe mal für die Macher das das im SafeRTOS nicht drin ist. So was würden sonst nie jemand ernsthaft in Sicherheitsrelevanten Geräten einsetzen. Ich habe mal in der Medizintechnik gearbeitet und kenne deren Anforderungen!
Dass C etwas lockerer wie andere Sprachen mit Typenpruefung umgeht war schon immer bekannt. Man muss etwas mehr mitdenken, sich etwas mehr konzentriern, oder andere Sprachen waehlen.
Nun aber mal halblang! Void-Pointer haben durchaus ihre Berechtigung und machen absolut Sinn. Schon mal die Standardlibraries Deines Compilers angeguckt? z.B. aus string.h: void *memcpy(void *, const void *, size_t); Dieser Funktion kann ja egal sein, was für Daten Du kopieren willst, daher die Void-Pointer.
dunno.. schrieb: > man kann ja durchaus void - pointer definieren, um z.b. in anderen files > keinen (wirklichen) zugriff auf die vom pointer referenzierten daten zu > bekommen - quasi datenkapselung... Der einzige, der die Kommentare in queue.c gelesen hat :-) Die Frage ware ja nicht, warum überhaupt Pointer auf void verwendet wurden, sondern warum der selbe Typ in der einen Datei so und in der anderen anders definiert wurde.
1 | /*
|
2 | * Inside this file xQueueHandle is a pointer to a xQUEUE structure.
|
3 | * To keep the definition private the API header file defines it as a
|
4 | * pointer to void.
|
5 | */
|
6 | typedef xQUEUE * xQueueHandle; |
(FreeRTOS 6.1.0) Gruß Marcus
Marcus Harnisch schrieb: > dunno.. schrieb: >> man kann ja durchaus void - pointer definieren, um z.b. in anderen files >> keinen (wirklichen) zugriff auf die vom pointer referenzierten daten zu >> bekommen - quasi datenkapselung... > > Der einzige, der die Kommentare in queue.c gelesen hat :-) hab die kommentare nicht gelesen, ich habs so gelernt.. ;) das ist halt objektorientiertes programmieren, ohne c++ oder klassen zu bemühen.. macht ja durchaus sinn, dem anwender nicht alles offen zu legen, damit er nicht alles kaputtpfuschen kann... soweit ich das gelernt habe, (vorallem im bezug auf echtzeit-betriebssysteme, die eben nur in C geschrieben sind) gängige praxis.
Herr Marcus Harnisch, auch ich habe diesen Kommentar gelesen und trotzdem hier gefragt. Meine Persönliche Meinung ist halt das so was unsauber ist. Bei memcpy ist ein Void Pointer verständlich aber innerhalb eines RTOS sollte so was nicht drin sein. Ich habe nichts gegen privat gehaltene Funktionen / Daten aber dann sollte man das sauber machen. Z.B. 2 Funktionen machen einmal mit Daten und einmal mit Void Pointer. Dann wird sich auch nie ein LINT oder anderes Tool beschweren. Ich bin über diese Stelle auch nur gestolpert weil ich ca. 30 Fehlermeldungen bekommen hatte und in meinen Kopf diese unsaubere Programmierung einfach nicht rein will. VG, Peter
Peter schrieb: > Ich habe nichts gegen privat gehaltene > Funktionen / Daten aber dann sollte man das sauber machen. Z.B. 2 > Funktionen machen einmal mit Daten und einmal mit Void Pointer. > Dann wird sich auch nie ein LINT oder anderes Tool beschweren. Peter schrieb: > Ich bin über diese Stelle auch nur gestolpert weil ich ca. 30 > Fehlermeldungen bekommen hatte und in meinen Kopf diese unsaubere > Programmierung einfach nicht rein will. C ist eine mächtige Sprache mit wenig Overhead, die viel Verantwortung dem Entwickler überträgt. Wem das zu viel ist, der kann ja gerne Richtung C# (.Net Micro)/Java (Nano VM, u.ä.) gehen - da ist alles "sicherer" ;). Fehlerfreier wird Soft-/Firmware dadurch ja nicht - siehe das ganze Zeug das da so rumschwirrt. Grundsätzlich sind LINT & Co nur Tools, die mögliche Schwachstellen aufzeigen sollen. Eine mögliche Schwachstelle oder Unschönheit ist aber noch lange keine. Die Interpretation ist wieder die Sache desjenigen der das Tool anwendet. Peter schrieb: > Ansonsten verstehe ich nicht wieso man einen solchen Schrott in einem > sonst so guten RTOS rein macht. > Ich würde als mein Chef jeden Angestellten (Kollegen) der mir so etwas > abliefert raus werfen. Alleine schon um alle Anderen zum vernünftigen > Programmieren an zuleiten. Du würdest auch jemand rauswerfen der Goto's verwendet oder? Alle derartigen Konstrukte haben ihre Berechtigung - Programmieren muss man eben können und lernen dazu gehören auch solche Konstrukte. Berechtigung hat jedes - für wohl überlegte Zwecke. FreeRTOS wird durch den void* ja nicht unsicherer. Intern wird der richtige Typ verwendet und das API "versteckt" den echten Typ. Klare Schnittstelle, nichts dubioses.
Wer bei uns ein Goto einbaut darf eine 20 Seiten Ausarbeitung schreiben, warum er das nicht anders lösen konnte oder gleich seine Papiere holen. Ein anderer Kollege darf das dann wieder raus holen. LINT & Co sind sehr gute Tools die helfen die Codequalität zu verbessern. Auch die MISRA Regeln und die entsprechenden Tools wurden ja nicht zum Spaß entwickelt. Es hilft nur nichts wenn man gezwungen ist Code zuschreiben der durch diese Tools kommt ohne eine Warnung und dann immer wieder auf Code stößt, der zwar von Tausenden Personen benutzt wird, aber nicht durch diese Tools kommt. Da wird man halt etwas nervös bei Sachen die zwar gehen, aber halt Warnungen Produzieren.
Peter schrieb: > Es hilft nur nichts wenn man gezwungen ist Code zuschreiben der durch > diese Tools kommt ohne eine Warnung und dann immer wieder auf Code > stößt, der zwar von Tausenden Personen benutzt wird, aber nicht durch > diese Tools kommt. Ja es zwingt dich aber keiner, FreeRTOS zu benutzen. Genauso wenig sind die Entwickler daran gebunden, sich an die Standards deiner Firma zu halten. Wenn ihr diese Auflage habt dann kauft euch ein RTOS, das diesen Standards genügt. Wo ist da das Problem?
OMG. In der Zwischenzeit wurden Wirth und Dijkstra für Ihre (abwertenden) Äußerungen über Goto's schon ... lassen wir das. Mir wurde gelernt goto's nicht zu verwenden -> 7-stufiges nesting lässt sich ja auch leichter lesen und nachvollziehen als goto :) Ein kompetenter Programmierer*) kann die verschiedenen Techniken nach Bedarf einsetzen. Btw. ich verwende goto sehr selten - meist in C Code der über Locking und I/O verfügt (also alle 1-2 Jahre 1x). Das Fehlerhandling kann sonst sehr unschön/unlesbar/komplex werden. Peter schrieb: > Es hilft nur nichts wenn man gezwungen ist Code zuschreiben der durch > diese Tools kommt ohne eine Warnung und dann immer wieder auf Code > stößt, der zwar von Tausenden Personen benutzt wird, aber nicht durch > diese Tools kommt. Wer zwingt dich dazu?! - Normalerweise muss man erklären können warum der Code so ist und warum das in diesem Fall akzeptabel ist - danach landet das im entsprechenden Dokument und die Sache ist erledigt. In meinen Augen ist LINT & Co sowas wie ein Messgerät für Codequalität und damit gilt das selbe wie für alle Messgeräte: Wer misst, misst Mist. Ich bin ein Freund von Code-Reviews bei kritischen Applikationen/Code Teilen - das deckt auch Fehler in "lt. LINT unbedenklichem Code" auf. Der Reviewer sollte dabei natürlich nicht am selben Code arbeiten und entsprechend kompetent sein. Jetzt mal ehrlich: Wenn es nicht Free RTOS wäre, sondern ein closed source Produkt, würdest du nicht mal wissen, dass das im Code passiert und es würde nichts an der Funktionalität ändern. *) das ist das Problem: Kompetenz - das setzt viel Erfahrung und Bildung voraus... Bei Neulingen oder Script Kiddies ists besser LINT und heftige Guidelines einzusetzen - da könnens immer noch genug "falsch" machen ...
Da sind halt die Vorgaben in der Firma so und über den Sinn könnten wir hier jahrelang Diskutieren. Die wollen das so und gut ist. Jeder der da arbeitet (ich nun >20 Jahre) weiß das und hält sich dran. Ein gekauftes OS wird aber immer mit Sourcecode geliefert/gekauft und wenn es nicht gefällt geht es zurück. Firmen Politik! Die Compiler werden übrigens auch mehrfach getestet! Erstrecht das fertige Produkt (bei jedem Update ein Volltest). Da das ARM Projekt mit dem FreeRtos ein privates Projekt ist, bin ich nicht an diese ganzen Vorgaben gebunden. Aber ich verwende halt die Tools in der Firma auch mal gerne bei den privaten Daten. Da kommen dann ganz schnell mal Fehler zutage die man ohne diese Tools noch nicht bemerkt hat und Tage lang suchen würde um die dann zu finden. Auch egal ob man SVN, CVS, .... benutzt, was ich jedem empfehlen würde, gibt es beim Start eines Projektes halt leider noch keine Historie. Und somit auch hier keine Hilfe bei Fehlern. Darum will ich halt sehen das ich nicht schon mit Fehlern starten. Ich habe inzwischen mir das im Debugger angesehen und an den komischen Stellen im FreeRtos scheint alles zulaufen. Wäre halt nur schön wenn die ganzen Tools keine Fehler darin vermuten würden.
Peter schrieb: > Da sind halt die Vorgaben in der Firma so und über den Sinn könnten wir > hier jahrelang Diskutieren. Der Grund warum ich mich bei diesem Thema meist ärgere ist die Delegation von Verantwortung an Programme (die von Menschen geschrieben wurden und daher per Definition fehlerbehaftet sind), ... - lassen wir das. Peter schrieb: > Da kommen dann ganz schnell mal Fehler zutage die man > ohne diese Tools noch nicht bemerkt hat und Tage lang suchen würde um > die dann zu finden. Zum Glück :) - Ich bin kein Gegner dieser Tools, sondern hab nur ein Problem damit, wenn deren Output als "Gesetz" betrachtet wird. Denn diese Tools sind dazu da in den meisten Fällen zu helfen, sie können das aber nicht immer. Peter schrieb: > Wäre halt nur schön wenn die ganzen Tools keine Fehler darin vermuten > würden. Auch dabei gebe ich dir recht :). Schön heißt aber nicht, dass etwas derzeit "unsauber", "schlampig", ... ist. Auch der IST-Zustand kann schöner sein - "beauty is in the eye of the beholder".
Da sind wir uns ja fast einig. Das Lint und co genauso wie Compiler Fehler haben können, wird ja leider immer wieder mal bestätigt. Ist meistens aber mehr bei den Compilern so. Das ist dann leider immer das schlimmste was passieren kann. Aber dafür gibt es dann entsprechend strenge Tests vom Produkt. Wenn ein Codechecker was meldet muss man sich so oder so die Stelle ansehen und da merkt man dann schon, ob das Tool einen Fehler hat. Nicht gefunden Fehler bemerkt man natürlich so nicht. Aber dafür setzt man halt mehrere Tools auf den Code an. Wenn man Jahrelang mit solchen Tools arbeitet merkt man aber schon das es der Fehlerrate der Produkte erheblich reduziert. Und somit unterstreichen sie das vorgehen der Firma (meinem Geldgeber). Was FreeRtos angeht, es läuft und ich verwende es jetzt einfach. Das es bessere gibt ist klar, aber die kosten dann halt auch einiges. Oder es sind freie die nicht portiert sind bzw nicht den Umfang haben und somit wegfallen. Auch der GCC ist dem Keil oder IAR unterlegen, aber ist auch wieder ein erheblicher Kostenunterschied. Für privat zum spielen reicht mir FreeRtos und GCC. Auch wenn ich damit regelmäßig einen Anfall bekomme, weil es nicht gleich funktioniert und ich erst Stunden suchen muss um das Problem zu lösen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.