Wie du schon geschrieben hast sind ca. 5% eines jeden Programmcodes fehlerhaft. Nur ist das Problem bei C++ das hier die Fehler sehr üble Folgen haben können während sich bei Sprachen wie z.B. Java/C#/Python der Schaden meist nicht gleich in einem BufferOverflow bemerkbar macht.
Ich halte einen Absturz teilweise für weniger schlimm, als ein unentdeckten Logikfehler, der z.B. Finanzbeträge verfälscht.
Ganz davon abgesehen habe ich bislang aus mehreren Projekten nicht feststellen können das C++ Programme schlimmere Fehler als beispielsweise Java- oder C#-Programme haben. Teilweise waren letztere sogar viel problematischer weil die Programmierer sich zu sehr auf die "Fehlerkorrektur" der Sprache verlassen haben.
efddfsfsdf schrieb:
Ich liebe die Systemsprachen auch über alles aber vom Sicherheitsaspekt sind sie Schrott. Da kannst du versuchen dich an alle Regel der Welt zu halten deine Anwedung wird fehlerhaft sein und bei C++ kann das ganz übel sein.
Ich sehe bei C++ kein Problem wegen Sicherheitsaspekten. Wo ich sie brauche, setze ich den entsprechenden Overhead für die Prüfungen ein. Und die Probleme des OP habe ich in dem Stil garnicht, da ich Rohe Arrays ohnehin vermeide, und bei unbekannten Datenmengen entweder sicherstelle das die Eingabe nach einer begrenzen Eingabemenge abbricht (sprich sich an den Grenzen orientiert), oder das die Datenstruktur entsprechen mitwachsen kann.
efddfsfsdf schrieb:
Aber so zum rumspielen mag ich die Sprache auch sehr, ist eine echte Herausforderung für jeden Programmierer.
Sie ist keine Herausforderung, verlangt aber wie jede Systemsprache, das man sich auf einer niedrigeren Ebene um die Behandlung kümmern muss, oder entsprechend eine Schicht darüber setzt. Die ersten Java-VMs waren intern häufig mit C++ geschrieben, nur wurden halt zwischen dem Entwickler und dem System noch Schichten eingezogen.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
Du würdest im Ernst sicherheitsrelevante Software lieber in einer Systemsprache dem Kunden empfehlen? E-Commerce, Krankenhaus, Banken, Raumfahrt, Militär, Behörden?
Zunächst mal möchte ich diese Statistiken sehen, und ich möchte sehen wie und auf welcher Datenbasis sie erhoben werden. Einen Mechanismus, Codezeilen zu identifizieren, die Fehler verursachen, fände ich außerordentlich praktisch. Obwohl ich meine Zweifel habe, wie sinnvoll es ist, Fehler in Zeilen zu messen - das ist schon für Codekomplexität eine ausgesprochen unbrauchbare Metrik, und Fehler entstehen häufig durch das Zusammenspiel verschiedener Codeteile, die für sich allein genommen durchaus korrekt sein können. Außerdem stellt sich die Frage, welche Programme dafür herangezogen werden; es ist beispielsweise davon auszugehen, dass du in Tutorials im Internet eine bedeutend höhere Quote verbuggter Software finden wirst als in Produktionscode.
Was die genannten Anwendungsfälle angeht:
Zu Krankenhäusern kann ich nicht viel sagen. Nach allem was ich höre, wird da viel in MUMPS gemacht.
In Behörden gibt es viele verschiedene Anwendungen, für die im Einzelfall das sinnvollste Werkzeug ausgewählt werden muss, generell reden wir hier aber hauptsächlich von alltäglicher Office-Software (Word, Excel etc.). Du kannst davon ausgehen, dass alles, was in einer Behörde verwendet werden soll, ohne großen Aufwand an solche Systeme anbindbar sein muss, und niemand schreibt Excel-Add-Ins in Java. Es sollte mich nicht wundern, wenn ein großer Teil dort verwendeter Software vom Sachbearbeiter selbst in Visual Basic zusammengeklickt wäre. Im Übrigen sei noch angemerkt, dass der Client für Phase 2 von ELSTER in ANSI-C entwickelt wird.
Bei Raumfahrt und Militär reden wir zu einem großen Teil von Embedded-Geräten; es sollte mich wundern, wenn da viele virtuelle Maschinen zum Einsatz kämen. Aller Wahrscheinlichkeit nach wirst du da viel C finden, und speziell in der Raumfahrt wohl auch einiges an FORTRAN.
Bei Banken kann ich dir sicher sagen, dass jede Mikrosekunde aus der Software rausgequetscht werden muss; in einer Zeit automatisierter Handelssysteme wäre alles andere ein großer Wettbewerbsnachteil. Auch sind in die Zusammenhänge in Kreditderivaten oft so komplex, dass du um eine Monte-Carlo-Simulation nicht herum kommst, und ob der (unter großer Anspannung stehende) Händler eine Minute oder eine halbe auf sein Ergebnis warten muss, macht in der Tat einen Unterschied. Selbstverständlich fängt man solche Dinge nah an der Maschine an.
Damit ist nicht gesagt, dass in diesen Bereichen nur Systemsprachen zum Einsatz kommen oder kommen sollten (das wäre unwahr), aber maschinennahe Sprachen kategorisch auszuschließen, kann sich niemand erlauben.
Davon unabhängig hat asc recht, dass Logikfehler das größere Problem sind - frag nur das Mars Climate Orbiter-Team der NASA. Oder die NYSE. Bei sicherheitsrelevanter Software ist vor allem wichtig, kompetente Entwickler zu finden und die Software ausgiebig zu testen (was kompetente Entwickler eh tun). Die Sprachwahl ist sekundär.
Einen Logikfehler schlimmer einzustufen als einen Buffer-Overflow halte ich für grob fahrlässig in einer Beratung. Wie hier schon beschrieben kann ein BO einfach mal einen Variabelinhalt verändern oder eine falsche Funktion aufrufen. Der berühmte Absturz wäre der Fall mit dem wenigsten Schaden.
Wenn Logikfehler eh immer vorkommen dann kommen diese ja bei den Systemsprache noch dazu, also haben wir es hier mit Logik- und Speicherfehlern zu tun.
Ich glaube mehr brauch man nicht sagen, es läuft darauf hinaus das man eine viel höheren Arbeitsaufwand hat wenn man eine Anwendung in einer Systemsprache erstellt. Wenn es nicht anders geht ok, aber sobald man eine Wahl hat wird diese mit Sicherheit heutzutage nicht mehr zugunsten eine Systemsprache ausfallen.
Einen Logikfehler schlimmer einzustufen als einen Buffer-Overflow halte ich für grob fahrlässig in einer Beratung.
1. Sind Bufferoverflows nicht so häufig wie hier gerne dargestellt werden, und man muss teilweise sogar absichtlich unsinnige Konstrukte dafür benutzen. Wer fixe Datenstrukturen für Eingaben undefinierter Länge einsetzt, ist mit jemanden vergleichbar, der Säure in ungekennzeichneten, öffentlich zugänglichen Gefäßen aufbewahrt.
2. Sind Zugriffsverletzungen (damit meine ich nicht nur Bufferoverflows) auch nicht so häufig, und nicht selten durch ebensolche Konstrukte, die man ohne weiteres meiden kann.
Auch in anderen Branchen gibt es Sicherheitsregeln bei deren Missachtung eine grobe Fahrlässigkeit darstellt. Systemsprachen ermöglichen zwar deutlich leichter einen Missbrauch, man kann sie aber grundsätzlich auch sehr sicher einsetzen. In anderen Sprachen muss man durchaus auch Regeln einhalten (z.B. in Sprachen, in denen Referenzen intern Zeiger sind die null annehmen können, hat man an Stellen, die nicht im Kontrollbereich liegen, auch eine Nullprüfung durchzuführen [z.B. würde ich bei privaten Methoden, die durch die Aufrufe null schon ausschließt, nicht Zwangsweise eine null-Prüfung der Parameter durchführen, bei einer öffentlichen schon]).
Vorsicht! schrieb:
Wenn Logikfehler eh immer vorkommen dann kommen diese ja bei den Systemsprache noch dazu, also haben wir es hier mit Logik- und Speicherfehlern zu tun.
Deren Gefahrenquelle man aber durchaus bereits durch eine entsprechende Programmierweise massiv einschränken kann.
Vorsicht! schrieb:
Ich glaube mehr brauch man nicht sagen, es läuft darauf hinaus das man eine viel höheren Arbeitsaufwand hat wenn man eine Anwendung in einer Systemsprache erstellt.
Aber nicht zwangsweise der Sicherheit wegen, sondern aufgrund des Schreibaufwandes (Was aber auch nicht zwangsweise stimmen muss, so können C++ Templates durchaus auch etliches an Schreibaufwand reduzieren).
Vorsicht! schrieb:
Wenn es nicht anders geht ok, aber sobald man eine Wahl hat wird diese mit Sicherheit heutzutage nicht mehr zugunsten eine Systemsprache ausfallen.
Wer sinnvoll auswählt, wird die Werkzeuge nach der Situation auswählen. Und das schließt Systemsprachen mit ein. Eine große, komplexe Unternehmensanwendung würde ich auch nicht mit einer Systemsprache schreiben, wenn auch nicht aus den hier immer so viel genannten "Systemfehlern", sondern wegen dem Schreibaufwand und der Tatsache das es in Sprachen wie z.B. Java und C# sehr viele Bibliotheken und Hilfsmittel gibt die, die Entwicklungszeit im Vergleich der Systemsprachen reduzieren.
_________________ in theory there's no difference between theory and practice. in practice there is. (yogi berra)
In der Theorie gibt es kein Unterschied zwischen Theorie und Praxis. In der Praxis sehr wohl.
Zunächst mal möchte ich diese Statistiken sehen, und ich möchte sehen wie und auf welcher Datenbasis sie erhoben werden. Einen Mechanismus, Codezeilen zu identifizieren, die Fehler verursachen, fände ich außerordentlich praktisch.
Ich finde es auch lustig einer automatisierten Lösung (sprich: Software) zu vertrauen, die herausfindet, dass 5% aller Codezeilen verbuggt sind
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum 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
