A large majority of OSes is coded in the C programming language (HelenOS is no exception to this). The choice of C in the case of kernel is usually wellmotivated, since the C language was designed specifically for implementing system software [10]: It is reasonably low-level in the sense that it allows to access the memory and other hardware resources with similar effectiveness as from assembler; It also requires almost no run-time support and it exports many features of the von Neumann hardware architecture to the programmer in a very straightforward, but still relatively portable way.
However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Zuletzt bearbeitet von Erhard Henkes am 14:29:15 29.08.2010, insgesamt 2-mal bearbeitet
... However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.
Viele Denkfallen und Fehler im C Quellcode lassen sich mit Hilfe der statischen Code-Analyse Tools wie splint aufdecken und vermeiden (es gibt auch entsprechende Tools für C++, kenne leider keine kostenlosen...).
Das andere Problem und meiner Meinung nach, das schwergewichtigere, ist:
Zitat:
In C, almost everything is left to the programmer who is free to set the rules.
... However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.
Viele Denkfallen und Fehler im C Quellcode lassen sich mit Hilfe der statischen Code-Analyse Tools wie splint aufdecken und vermeiden (es gibt auch entsprechende Tools für C++, kenne leider keine kostenlosen...).
Das andere Problem und meiner Meinung nach, das schwergewichtigere, ist:
Zitat:
In C, almost everything is left to the programmer who is free to set the rules.
Splint... Ich habs tatsächlich versucht, es hat _nur_ Müll ausgegeben, keinen sinnvollen Hinweis unter ca. 5000 Hinweisen.
Cppcheck find ich persönlich besser, kann mit C und C++ umgehen.
Zuletzt bearbeitet von Mr X am 19:22:21 29.08.2010, insgesamt 1-mal bearbeitet
Splint... Ich habs tatsächlich versucht, es hat _nur_ Müll ausgegeben, keinen sinnvollen Hinweis unter ca. 5000 Hinweisen.
Ja, ich weiss, dass man Tausende Warnungen bekommt, aber ich habe die Erfahrung gemacht, dass jede Warnung einen Bug bedeuten kann... d.h. in den 5000 Warnungen würde ich jetzt 5000 potentielle Bugs sehen...
Mr X schrieb:
Cppcheck find ich persönlich besser, kann mit C und C++ umgehen.
Ja, ich weiss, dass man Tausende Warnungen bekommt, aber ich habe die Erfahrung gemacht, dass jede Warnung einen Bug bedeuten kann... d.h. in den 5000 Warnungen würde ich jetzt 5000 potentielle Bugs sehen...
Ein Teil der Meldungen kam daher, das es nicht mit C99 oder GCC-spezifischen Dingen klarkam (leider brach er daraufhin jedes Mal ab - ich musste jede Datei separat checken). Ein Problem, das cppcheck übrigens nicht hat. Dann waren die meisten Fehlermeldungen so formuliert, das man nicht verstand, was es von einem will. Oft beklagte er sich auch nur, weil man selbst einige Dinge definiert, die ein Anwendungsprogramm einfach aus der Standardlib beziehen würde (malloc, free, size_t, ...). Richtig war allerdings, das man keine Namen mit _ am Anfang verwenden sollte, da das für den Compiler "reserviert" ist.
und da sagt splint mehrmals "A memory leak has been detected" u. ä. oder Rückgabewerte von Funktionen unbenutzt, oder unsigned mit signed gemischt, oder untereinander nicht kompatible Datentypen gemischt u. ä. Hört sich alles nicht so gut an
<--- das ist interessant. Wir kontrollieren ja bereits mit dem heap logger und überwachen auch den physischen Speicher auf leaks. Da ist mir momentan nix aufgefallen.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können keine Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum nicht antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
