Bugs in der STL

Nexus

knivil schrieb:

Desweiteren ist das Statistik, d.h. viele schlechte und durchschnittliche Programme/Programmierer. Daraus eine Unmoeglichkeitsaussage abzuleiten, ist Bullshit.

Ne, eben gerade nicht. Es ist praktisch unmöglich, ab einer gewissen Komplexität bugfreie Programme zu schreiben. Natürlich funktioniert Bugfreiheit in der Theorie, aber in der Praxis muss man eben gerade Faktoren wie durchschnittliche Programmierer, Budgets und Deadlines berücksichtigen. Fehler können auf jeder Stufe deiner Liste passieren, sie wegzudiskutieren ist idealistisch.

knivil schrieb:

Sie gehoeren nicht mir, sondern meiner Firma.

Was ist für dich komplex? Gängige Betriebssysteme, Browser und Office-Programme sind ein gutes Beispiel. Die enthalten alle Bugs und werden ständig verbessert. Es sind auch deswegen gute Beispiele, weil sie von extrem vielen Leuten benutzt werden, und sich Bugs deshalb eher zeigen. Wenn ein Programm nur von einer Handvoll Leute eingesetzt wird, kann es gut sein, dass viele Fehler unentdeckt bleiben.

...verdammt, jetzt habe ich mich doch wieder auf eine aussichtslose Diskussion eingelassen.

knivil

Es ist praktisch unmöglich, ab einer gewissen Komplexität bugfreie Programme zu schreiben.

Ich habe dich verstanden.

Budgets und Deadlines

Kenne ich, habe ich. Nur halte ich mich nicht fuer einen durchschnittlicher Programmierer.

Wenn ein Programm nur von einer Handvoll Leute eingesetzt wird, kann es gut sein, dass viele Fehler unentdeckt bleiben.

Medizinprodukte. Sie wird von vielen eingesetzt. Nicht von Millionen wie bei Office. Was meinst du, wie teuer dort Fehler sein koennen? Ich sage dir: Es ist sehr ... unwirtschaftlich.

Ich wiederhole meine Frage: Was fehlt dir an Werkzeugen, um fehlerfreie Software zu produzieren? Ich gehe noch weiter: Was fehlt dir an Werkzeugen, um performante, sichere und fehlerfreie Software zu produzieren?

knivil schrieb:

Was fehlt dir an Werkzeugen, um performante, sichere und fehlerfreie Software zu produzieren?

Ihm fehlt das Wissen um funktionale Programmierung.

asc

knivil schrieb:

Warum sollte das nicht ausreichen, fehlerfrei Software zu produzieren?

Fängt schon dabei an, das Anforderung in der Regel niemals 100% abgebildet werden kann. Sei es wegen Reibungsverlusten zwischen Anwender, Analytiker und Entwickler, sei es weil Software immer nur eine vereinfachte Abbildung der Realität sein kann.

Man kann Software möglichst fehlerfrei, aber nicht absolut fehlerfrei schreiben. Du kannst gerne etwas anderes behaupten, nur halte ich es für ein absolutes Wunschdenken. Daran ändert auch nichts, das es ein kritischer Bereich ist. In einem solchen Versucht man nahe der 0-Fehlergrenze zu kommen, Fehler gänzlich ausschließen zu können halte ich für reine Utopie.

Jedes Programm, ab einer gewissen Größe, hat Fehler, darüber muss man nicht reden, das ist einfach so von Natur aus gegeben. Die Frage ist nur wie viele Fehler es sind. Bei der Nase dürfen es nur wenige auf 100.000 Zeilen Code sein, woanders natürlich mehr.

Ein Grund warum Menschen keine fehlerfreien Programme schreiben können, mag der sein, dass das menschliche Gehirn nicht dafür geschaffen ist objektiv und im großen Ganzen denken zu können.

NASAmachtFehler schrieb:

Bei der Nase dürfen es nur wenige auf 100.000 Zeilen Code sein, woanders natürlich mehr.

Hab gerade einen tollen Link gefunden, wie die Nase das macht:
http://forums.udacity.com/questions/12000321/nasa-is-coding-in-python

Einfacher Code, bei dem sofort klar ist, was er macht (d.h. kein unverständliches C++-Zeugs wie hier oft angepriesen) mit vielen Assertions scheint auszureichen.

Woran es oft scheitert, ist

knivil schrieb:

4.) Module koennen fehlerfrei verknuepft werden.

=> Wie geht man da vor, knivil?

firefly

asc schrieb:

Dann erkläre mir einmal was daran kritisch ist, wenn hier Korrekturen zu einem Compiler genannt werden, der bereits 2 Nachfolgegenerationen hat. Und noch dazu wenn der Autor die Fakten nicht richtig nennt.

welche 2 nachfolge Generationen? Der titel des blog posts ist
"STL Bugs Fixed In Visual Studio 2012"
Und da im erst November 2013 VS 2013 released wurde ist diese liste höchstens für die Vorgänger version vom aktuellen Visual Studio

asc

firefly schrieb:

...
"STL Bugs Fixed In Visual Studio 2012"
Und da im erst November 2013 VS 2013 released wurde ist diese liste höchstens für die Vorgänger version vom aktuellen Visual Studio

Es sind Fehler die in 2010 waren, aber in 2012 behoben sind. Daher: 2 Nachfolger (2012, 2013).

asc

knivil schrieb:

Nenne mir bitte auch nur ein komplexeres Programm das du als fehlerfrei ansiehst. Mir ist bis heute jedenfalls bewusst noch kein einziges untergekommen.

Sie gehoeren nicht mir, sondern meiner Firma.

Muss eine Klasse für sich sein, deine Firma. Braucht keine QS (den wenn eine solche auch nur einen Fehler finden könnte ist deine Aussage hinfällig. Wenn nachträglich ein Fehler festgestellt wurde, kann man niemals einen weiteren ausschließen), kein Bugtracking...

otze

knivil schrieb:

1.) Module koennen fehlerfrei geplant werden

Die einzige Umgebung in der ich es für möglich halte sind medizinische Anwendungen, weil sie komplett und zu 100% durchspezifiziert sein müssen. Un selbst dann wird für medizinische Anwendungen keine fehlerfreiheit verlangt, allerdings eine extrem niedrige Buganzahl. Es gibt auch mehr als genug medizinische Projekte die trotz dieser Rahmenbedingung einfach scheitern.

Leute die meinen 100% fehlerfreie Software schreiben zu können, die diskreditieren sich doch mit solcher Aussage schon selbst. Wenn du so etwas kannst, brauchst du dir um Geld keine Sorgen mehr zu machen. Vielleicht ist er aber ja auch schon Multimilliardär, wer weiß? Dann könnte er ein Buch darüber schreiben, was sie ihm aus den Händen reißen würden.

Also Knivil du bist in der Bringschuld, wie schreibt man 100% ferhlerfreie Software?

knivil

Un selbst dann wird für medizinische Anwendungen keine fehlerfreiheit verlangt, allerdings eine extrem niedrige Buganzahl. Es gibt auch mehr als genug medizinische Projekte die trotz dieser Rahmenbedingung einfach scheitern.

Es geht um Aussagen zu bugfreiheit wie "nahezu unmoeglich" und "unwirtschaftlich".

Weitere Beispiele: Wie witschaftlich ist es wenn Autohersteller ihre Autos zurueckrufen muessen wegen eines Softwarefehlers?

Anzahl der User: Steuerung einer Industrieanlage (wird also nur von einer Firma benutzt). Wie wirtschaftlich ist es eine Fertigungsstrasse eine Woche abzuschalten, um Softwarefehler zu fixen.

Was sind wohl die Auswirkungen von Softwarefehlern bei Flugzeugen, Bussen und Bahnen?

Also Knivil du bist in der Bringschuld, wie schreibt man 100% ferhlerfreie Software?

1.) Nein, bin ich nicht. Du versuchst mich einfach nur blosszustellen.
2.) Frage: Was fehlt dir, um siche Software zu entwickeln?
3.) Schaue dir bitte die Entwicklungsprozesse bei Automobilherstellern, Flugzeugen, ... etc. blabla an.

Es gibt auch mehr als genug medizinische Projekte die trotz dieser Rahmenbedingung einfach scheitern.

Es geht mir nicht um Projekte, das ist zu schwammig. Es geht um ein Stueck komplexer, groesserer Software. Es muss kein Programm sein, Bibliothek reicht. Warum ist soll es unmoeglich sein, diese fehlerfrei zu entwickeln?

Die einzige Umgebung in der ich es für möglich halte sind medizinische Anwendungen, weil sie komplett und zu 100% durchspezifiziert sein müssen.

Es gibt genug andere Beispiele. Nein muessen sie nicht. Warum soll es nur mit einer kompletten Speazifikation moeglich sein, fehlerfrei Software zu produzieren? Desweiteren reichen auch nichtkritische Fehler aus, damit die Zulassung entzogen wird. D.h. das Produkt kann nicht weiter verkauft werden. D.h. Bugfixing + Neuzulassung. D.h. sehr viel Zeit ohne Einnahme + Imageschaden. Aber hey: Ist ja wirtschaftlich ...

Es wundert mich nicht, dass ungefragt das allgemeine Mantra wiederholt wird, wenn Office, Outlook oder Mediaplayer als Messlatte/Vorstellung herhaelt.

Und dann kommen dumme Bemerkungungen, die nichts damit zu tun haben, wie

Muss eine Klasse für sich sein, deine Firma. Braucht keine QS

Auf einmal werden alle zu Trollen, weil ihre beschraenkte Sichtweise sie im Recht sieht.

volkard

asc schrieb:

knivil schrieb:

Kein Programm ist fehlerfrei (wenn man vielleicht einmal von einem Hello World absieht)

Bullshit!

Du magst es als Bullshit bezeichnen, es gibt sogar diverse Studien zu dem Thema.

Oh, das ist ja ein scharfer Nachweis.

Also mir geht es eher so wie knivil, ich brauche im täglichen Geschäft keinen Debugger. Klar, Fehler sind unvermeidbar. Je später sie auftauchen, desto teurer werden sie. Aber naja, mit ein wenig Umsicht kann man quasi alle Fehler daheim behalten.

otze

knivil schrieb:

Weitere Beispiele: Wie witschaftlich ist es wenn Autohersteller ihre Autos zurueckrufen muessen wegen eines Softwarefehlers? werden alle zu Trollen, weil ihre beschraenkte Sichtweise sie im Recht sieht.

Gegenbeispiel: Die automatische Steuerkorrketur von Flugzeugen wird in heutigen Maschinen von 3 unabhängigen Firmen implementiert. Der Steuercomputer berechnet dann die Befehle aller 3 Programme in Parallel und führt die Mehrheitsentscheidung aus.

Du wirst wohl zugeben müssen, dass ein abgestürztes Flugzeug für den Flugzeugbauer teurer ist als das Stillstehen einer Fertigungsstraße. Und offensichtlich ist das Verhalten eine Kapitulation vor der Komplexität - niemand kann beweisen dass eine der 3 implementierungen richtig ist. Und ohne beweisbare korrektheit hast du keinen Beweis für ein fehlerfreies Programm. Empirisch kannst du die Nicht-Existenz von Fehlern nicht beweisen, nur die Existenz.

Mich würde jetzt aber auch interessieren, wie man im Allgemeinen fehlerfreie Software einfach "schreibt". Das klingt für mich so, als sei der Code von Anfang an fehlerfrei (und das vor allem mit einem gesunden Vertrauen darin) und nicht erst durch extensives Testen aller Randfälle. Leider nur schreibt ihr ja nichts über Strategien dafür, sondern versucht die anderen aus der Reserve zu locken, warum sie denn meinen, soetwas nicht zu können.

Mein !unqualifizierter! Eindruck ist es, dass medizinische Geräte und Software in kritischen Teilen von Autos/Flugzeungen, die ihr hier als Beispiel anführt, zur simpleren Sorte gehören (das meine ich nicht abwertend: in solchen Fällen kann man und muss man dann die Möglichkeit nutzen, das ganze besser zu Analysieren, als es bei riesigen integrierten Softwaresystemen überhaupt praktikabel ist). Erstmal verwenden sie Technologie "von Gestern" und müssen nur in ganz stark eingeschränktem Maße vom Nutzer bedient werden (Also Winkel- und Streckengeber die am Anfang des Zyklus ausgewertet werden, oder deren zyklische Auswertung den nachgelagerten Auswertungszyklus anstößt). Eingabe => _mathematisch_ (Analysis) geprägte Berechung => Ausgabe.

Das im Gegensatz zu Desktopsoftware, bei der der mathematisch beschriebene Schwerpunkt viel eher durch allgemeine Logik beschrieben wird, und bei dem Eingaben von überall herkommen, zu jedem möglichen Zeitpunkt. Desktopsoftware muss vor allem aber auch explizit inkonsistente Datenzustände zulassen, weil der Mensch es nunmal mag, iterativ anzupassen, ohne dass die Software ihm ungültig gewordene Eingaben zunichte macht.

Wenn ich "Endlosschleifen-Software" für Mikrocontroller schrieb (Eigentlich dasselbe wie Spieleprogrammierung, bevor das Multithreading Einzug erhielt), dann war ich auch erstaunt, wie gut die doch eigentlich funktioniert und wie wenig Ärger das ganze macht.
Da kann man dann davon ausgehen, wenn die Zeitanalyse sagt, dass der Zyklus in den Schlitz passt und die Kommunikationssysteme durchgetestet sind, dass das ganze recht wenig Fehlerpotential besitzt. Und vor allem kann man der Verpflichtung entsprechen, das in großen Teilen auch nachzuweisen (also Zeitanalyse, mathematisches Modell, umsetzung des mathematischen Modells).

Um zum Auto zurückzukommen: Kennt ihr das Beispiel der Toyota-Gaspedal-Software? Es hat mich schon erstaunt, wieso man da solch einen komplexen Ansatz verfolgt hat mit Echtzeitbetriebssystem, mal von der letztendlichen Implementierung abgesehen.

So, ich hab mir jetzt die Mühe gemacht, etwas zu schreiben und vor allem möchte ich nicht trollen, ich möchte einfach nur einschätzen können, was ihr eigentlich wirklich damit meint (Randbedingungen, in welchem Gebiet, vor dem Testen oder danach, etc.), wenn ihr sagt, man kann Software fehlerfrei schreiben und vor allem Strategien dazu kennenlernen.

decimad schrieb:

Desktopsoftware muss vor allem aber auch explizit inkonsistente Datenzustände zulassen, weil der Mensch es nunmal mag, iterativ anzupassen, ohne dass die Software ihm ungültig gewordene Eingaben zunichte macht.

Ich kann mir gerade nichts darunter vorstellen. In Formularen hast du erstmal unvalidierte Eingabe, was die Software als bedeutungsloser Datensatz versteht und wenn auf "übernehmen" gedrückt wird, wird das validiert und wird nur aktzeptiert, wenn es konsistent ist. Da ist nirgendwo ein inkonsistenter Zustand.

Oder jedenfalls nicht inkonsistent aus Sicht der Software, denn wenn das passiert, hast du schon einen Bug.

Ich sehe das Problem eher, dass man bei Desktop-Software mit Technologien arbeitet, die man nicht vollständig durchschaut, während mathematische Modelle formalisierbar und dadurch durchschaubar sind. Dann macht man in jeder zweiten Codezeile implizite Annahmen über einen globalen State, was auch auf in den trivialen Tests funktioniert. Irgendwann schleichen sich Inkonsistenzen ein (ungewollt!) und man hat einen Bug.

Viele Fehlerklassen kann man aber effektiv vermeiden, Nullpointer-Zugriffe oder double-deletes, etc. sind Sachen, die einem die Sprache abnehmen. Ausser man versteht es nicht, die Sprache so zu nutzen, dann hat man ein grösseres Problem und soll schleunigst von C++ auf sicherere Sprachen wechseln.

@zunichte: Ich meine so Dinge, wie zB. Zyklen in einem Graph zulassen, der am Ende aber nicht zyklisch sein darf. Der während der Konfigurationsphase aber schon verbindungsspezifische Parametrierungsdaten erhält, wo man also nicht einfach irgendwelche Kanten löschen kann um die Invariante "nicht zyklisch" einzuhalten. Das fällt mir aktuell dazu ein, weil ich den Fall hatte.

Klar, Datenbankformular-Anwendungen sind da was anderes, da kann man ja ohne Probleme den kompletten, in sich inkonsistenten Datenbestand, außerhalb des eigentlichen Datenmodells halten. Vor allem stellt man dort Veränderungen auf aggegierter Formularbasis an, also ein "commit". Das ist ja ein bisschen anders, als würde man iterative Veränderungen direkt am Datenmodell zulassen.

Fehlerfrei programmieren ist eine Sache. Fehlerfrei entwickeln und genaue Anforderungen bestimmen ist die andere. Am Ende kommt der Kunde der eine entwickelte Lösung aber vielleicht als Fehler ansieht.

Für mich sind die besten Kommentare im Sourcecode immer Sätze mit "richtig".

"Jetzt holen wir das berechnete richtige Ergebnis aus Klasse XY"

dot

Was genau bedeutet eigentlich "fehlerfrei"?

junta

knivil schrieb:

Weitere Beispiele: Wie witschaftlich ist es wenn Autohersteller ihre Autos zurueckrufen muessen wegen eines Softwarefehlers?

Bleib lieber bei deiner Medizin... Bei dem was mir bei Steuergerätsoftware an Code untergekommen ist . Das war hässlichstes C! Das ist mit Sicherheit nicht fehlerfrei, auch wenn es die Testfälle bestanden hat