Bugs in der STL
-
@Knivil: Keine einzige Software von Autos, Flugzeugen, Raumfähren und Stationen besitzt 100% fehlerfreie Software. Wie lange bist du in der Branche, eine Femtosekunde?
-
knivil schrieb:
Die Fehlerfreiheit einer Software zu zeigen erfordert doch Argumentation.
Ich moechte nicht die fehlerfreiheit beweisen. Aber fuer dich wiederhole ich mich nochmals: Es gibt viel Literatur ueber Entwicklungsprozesse. Diese sind in den einzelnen Industriezweigen verschieden. Bei mir reichen Disziplin und Unittests gekoppelt and Memoryleak und code coverage tools aus. Letztere sind hilfreich, dienen aber hauptsaechlich dazu, andere zu ueberzeugen.
Und du glaubst, das alle anderen hier, die den Gegenstandpunkt vertreten dümmer sind als du? Ich behaupte nicht das man die Qualität einer Software gar nicht steuern kann, behaupte aber das es schlicht unmöglich ist (eine Ausnahme mögen mathematisch exakt belegbare Algorithmen sein) eine Software fehlerfrei zu bekommen. Ja, man kann sie Fehlerarm und Robust designen, aber Fehlerfrei ist etwas anderes.
Und wenn du meine Anspielung darauf das ihr dann auch keine QS braucht, oder diese zumindest nicht einen Fehler finden darf als Trollen ansiehst, kann ich dich nicht ernst nehmen. Fakt ist, das wenn irgendein anderer einen Fehler findet, man davon ausgehen kann, das keine 100%ige Fehlersicherheit gewährleistet werden kann. Man kann in gewissen Spezifikationsgrenzen vielleicht relativ fehlerfrei sein, aber weder UnitTests noch Memoryleaks und Code Coverage Tools können eine Fehlerfreiheit garantieren.
Das erinnert mich an meine Kindheit, als ein Arzt Probleme mit einem Messgerät bekam, weil meine Schwester ein höheres Fieber hatte als dieses vorsah (Ich weiß nicht wo die Grenze liegt, aber rein von den Geräten her hätte sie von der Temperatur nach dem Instrument her tot sein müssen).
Ich kenne durchaus auch am Rande das ein oder andere aus der Automobilbranche, auch wenn ich selbst niemals in dem Bereich tätig war (wohl aber Bekannte). Man kann noch so viel spezifizieren, es gibt immer mal Zustände, die so nicht vorgesehen waren.
Jedes Programm ist (von mathematischen Algorithmen vielleicht zum Teil einmal abgesehen) nur eine Vereinfachung der Realität. Ein Gerät und ein Programm kann im besten Fall nur mit dem sauber umgeben, wofür es Spezifiziert wurde. Eine komplette Abdeckung aller noch so unwahrscheinlichen Fälle ist in der Regel nicht spezifizierbar. Und auf jeder Ebene, sei es Spezifikation/Entwurf, Entwicklung und Test und selbst im Einsatz kann immer etwas passieren.
Man kann die Fehlerwahrscheinlichkeit senken, dies geht je Komplexität eines Gesamtsystems, nach Mittelaufwand, nach Zeitrahmen auch sehr gut, aber fehlerfrei arbeitet keiner.
Und was Aussagen wie "Ich bin ein sehr guter Programmierer" angeht... Ich bin inzwischen bei solchen Angaben mehr als nur sehr vorsichtig. Gerade wer sich für nahezu perfekt hält, kann leicht mit Scheuklappen durchs Leben rennen.
Ich selbst saß leider nie in einem Projekt das dem Ideal sehr dicht kam, aber die Kunden waren auch nicht Krösus und konnten sich auch schlicht nicht alles leisten (Man steht immer im Konflikt zwischen Zeit, Kosten und Funktionalität). Von Termindruck mal ganz abgesehen. Ich kenne aber durchaus Techniken um Fehler schon möglichst frühzeitig zu reduzieren, aber kein Buch in der Literatur die ich gelesen habe hat je behauptet das ein Mittel jemals Fehler ganz ausschließen kann. Ins Besondere Bücher zu Unittests schreiben gerne mal herein, das man niemals alle Fälle finden und spezifizieren kann, man kann aber je nach Aufwand näherungsweise an eine Komplettabdeckung kommen.
-
Ich habe hier ein nicht-triviales Programm zu Beleuchtungssteuerung. Das ist zustandsbehaftet. Laeuft auf auf einem Mikrokontroller, kommuniziert ueber RS232 nach aussen. Ein formaler Beweis der Korrektheit ist vielleicht moeglich, aber nicht praktikabel oder gar notwendig. Es wurde mit spezifischen Anforderung in endlicher Zeit erstellt. Es kann mit mehr als den spezifizierten Ausnahmesituationen umgehen. Es kann leider nicht damit umgehen, wenn das Geraet hart mit einem Hammer getroffen wird. Ist es deswegen fehlerhaft?
Damit widerlege ich folgende Aussage:
Kein Programm ist fehlerfrei (wenn man vielleicht einmal von einem Hello World absieht)
Kann ich das auch anderen beweisen? Nein! Brauche ich auch nicht, die Software wird dadurch nicht besser. War dazu ein Theorembeweiser noetig. Nein!
-
knivil schrieb:
Damit widerlege ich folgende Aussage:
Kein Programm ist fehlerfrei (wenn man vielleicht einmal von einem Hello World absieht)
Ähm...nein tust du nicht, denn um diese Aussage zu widerlegen, müsstest du beweisen, dass deine Software fehlerfrei ist!?
-
Und wie soll ich hier den Beweis erbringen? Anforderungen, System, Hardware, Software und Use cases offenlegen? Darf ich nicht, kann ich nicht!
-
knivil schrieb:
Und wie soll ich hier den Beweis erbringen?
Gar nicht, der Beweis ist rein prinzipiell nicht möglich, genau das ist ja eben das Problem hier!?
Falls du tatsächlich einen Weg findest oder gar kennst, die Fehlerfreiheit von Software zu beweisen, dann solltest du diesen unbedingt publizieren, Turing Award und Fields Medal sind dir sicher...
-
@knivil: Bist du so arrogant, dass du nicht zugeben kannst wenn du absoluten Müll erzählt hast, oder einfach nur dumm? Ich hoffe nur, dass niemand einen Software-Entwickler bezahlt, der behauptet 100% fehlerfreie Software abliefern zu können. So einen Honk haben wir mal in einem C64-Forum gehabt, war ein Informatik-Student und ich hoffe dass den niemand einstellt.
-
Fall du tatsächlich einen Weg findest oder gar kennst, die Fehlerfreiheit von Software zu beweisen, dann solltest du diesen unbedingt publizieren, Turing Award und Fields Medal sind dir sicher...
Es geht nicht um den Allgemeinen Fall.
-
Mal als Anmerkung: Fehlerfreiheit beliebiger Software zu beweisen ist a priori etwas anderes und vor allem schwerer als fehlerfreie Software zu konstruieren.
-
Bashar schrieb:
Mal als Anmerkung: Fehlerfreiheit beliebiger Software zu beweisen ist a priori etwas anderes und vor allem schwerer als fehlerfreie Software zu konstruieren.
Das mag sein, aber auch für das konkrete Beispiel sollte das bereits unmöglich sein!? In keinem Fall ist allerdings wäre "Anforderungen, System, Hardware, Software und Use cases offenlegen" ein Beweis...
-
Das mag sein, aber auch für das konkrete Beispiel sollte das bereits unmöglich sein!?
Ich frage mich, warum viele auf "Unmoeglichkeit" bestehen. Unter welchen Voraussetzungen ist es denn nicht unmoeglich? Es wirkt auch leicht widerspruechlich, eine Art formalen Beweis zu fordern, aber auf der anderen Seiten so unkonkret zu sein.
In keinem Fall ist allerdings wäre "Anforderungen, System, Hardware, Software und Use cases offenlegen" ein Beweis...
Nein, es versetzt dich aber in die Lage, dich selbst zu ueberzeugen. Es ist die Grundvoraussetzung der Ueberpruefbarkeit. Da das nicht gegeben ist, kannst du mir glauben oder eben nicht. Ich kann erahnen, fuer was du dich entscheidest.
-
knivil schrieb:
Ich habe hier ein nicht-triviales Programm zu Beleuchtungssteuerung. Das ist zustandsbehaftet. Laeuft auf auf einem Mikrokontroller, kommuniziert ueber RS232 nach aussen. Ein formaler Beweis der Korrektheit ist vielleicht moeglich, aber nicht praktikabel oder gar notwendig. Es wurde mit spezifischen Anforderung in endlicher Zeit erstellt. Es kann mit mehr als den spezifizierten Ausnahmesituationen umgehen. Es kann leider nicht damit umgehen, wenn das Geraet hart mit einem Hammer getroffen wird. Ist es deswegen fehlerhaft?
Ach, da kann ich unmengen an Gegenbeispiele bringen.
Folgendes zB:
Mein Vater hatte mal mit einer Software zu tun die irgendwas tat und dann bei einer Änderung der Daten automatisch ein Backup auf Floppy Disc erstellt hat. Hat einwandfrei funktioniert. Die Daten wurden auf die Festplatte und auf die Floppy geschrieben. Nur manchmal 2-3 im Jahr war ein Datenstand auf der Floppy Schrott. Das war egal weil es bei der nächsten Änderung eh wieder in den Korrekten Zustand gesetzt wurde. Es ist deshalb auch ein gutes Jahrzehnt nicht aufgefallen. Ein Jahrzehnt(!) während es in etlichen Betrieben täglich verwendet wurde.Im Endeffekt hat mein Vater den Fehler dann gefunden, eine Funktion war nicht reentrant safe. Trivial. Aber hat sich halt nur ganz ganz selten gezeigt der Fehler. Auch wenn es Niemanden aufgefallen ist.
Ich habe einige solche Anekdoten - ist nur langweilig das hier zu zitieren. Software kann Jahrzehnte lang "fehlerfrei" laufen bis man einen Fehler entdeckt.
-
knivil schrieb:
Es wirkt auch leicht widerspruechlich, eine Art formalen Beweis zu fordern, aber auf der anderen Seiten so unkonkret zu sein.
Nope. Nichts unkonkret. Bleib bitte sachlich.
Die Forderung ist nach einem Formalen Beweis der Fehlerfreiheit. Den du nicht erbringen kannst. Keiner kann das. Ergo ist Fehlerfreie Software unmöglich. Denn wenn sie möglich wäre, müsstest du es ja beweisen können, oder?
Zu Beweisen dass Software Bugs haben kann, ist dagegen trivial. Fast jede Software hat einen eigenen Bugtracker wo die gefundenen Bugs gelistet sind.
-
Anekdoten habe ich auch genug, die meisten fallen unter NDA. Ich will auch gar nicht abstreiten, dass Software fehlerhaft sein kann. Es ist sogar sehr wahrscheinlich, dass Software fehlerhaft ist. Akzeptabel ist fuer mich trotzdem nicht. Das allgemeine Mantra/Sing-Sang geht mir auf den Keks. Deswegen ist es mir eigentlich auch nicht wichtig zu beweisen, ob ich oder andere fehlerfreie Software produzieren oder nicht.
Wichtig ist fuer mich, was mich in die Lage versetzt, fehlerfreie Software zu produzieren. Was sind die Umstaende und wie aufwendig es ist, sie herzustellen.
Ergo ist Fehlerfreie Software unmöglich. Denn wenn sie möglich wäre, müsstest du es ja beweisen können, oder?
Nein, Software hat Fehler oder eben nicht. Unabhaengig, ob ich einen Beweis anstrebe oder eben nicht. Normalerweise aber: Da die Fehlerfreiheit nachtraeglich schwer zu beweisen ist, soll sie durch den Konstruktionsprozess gesichert werden. Aber nur weil in jedem Konstruktionsschritt fehler auftreten koennen, heisst das noch lange nicht, dass wirklich Fehler aufgetreten sind.
-
Ich finde die Diskussion zwar sowieso nicht so toll, aber die Argumentation
Shade Of Mine schrieb:
Die Forderung ist nach einem Formalen Beweis der Fehlerfreiheit. Den du nicht erbringen kannst. Keiner kann das. Ergo ist Fehlerfreie Software unmöglich. Denn wenn sie möglich wäre, müsstest du es ja beweisen können, oder?
kann ich nicht nachvollziehen.
Die Riemannsche Vermutung ist (noch) unbewiesen. Keiner kann sie beweisen.
Sie ist also falsch, denn wäre sie richtig, müsste man sie ja beweisen können.
Oder wie?
-
knivil schrieb:
Das allgemeine Mantra/Sing-Sang geht mir auf den Keks.
Dein Gelabere langweilt mich auch schon eine Ewigkeit. DU bist also mit Abstand klüger als alle anderen, denn die haben nachweislich verbuggte Software produziert, und sei es nur die Annahme, dass ein Programm nicht länger als 99 Jahre läuft...
Wenn man mal von kleinen Programmen auf einem Microcontroller absieht, verwendet man idr. auch Libraries von anderen, deren fehlerfreiheit man nicht garantieren kann.
Und wie festgestellt, nützt dir ein fehlerfreier Quelltext nichts, wenn der Compiler ein fehlerhaftes Compilat erstellt.
Traurig, dass man darüber ewig diskutieren muss
-
Programme mit <10 Codezeilen scheinen fehlerfrei umsetzbar zu sein. Und Programme mit 11 Zeilen? Ich behaupte mal, bis 1000 Zeilen ist fehlerfreiheit gut machbar, wenn mans drauf anlegt.
Wenn man dann das Programm ganz klar in Module mit <1k Zeilen unterteilt und diese zusammensetzt sollte das Endergebnis auch wieder fehlerfrei sein, wenn es nicht allzu viele Module sind.
Also hätte man mit etwas Sorgfalt 100k Zeilen grosse Projekte erzeugt.
Von den praxisnahen Alles-ist-Buggy-Verfechtern:
junta schrieb:
Und wie festgestellt, nützt dir ein fehlerfreier Quelltext nichts, wenn der Compiler ein fehlerhaftes Compilat erstellt.
Wie oft ist dir das schon mal passiert?
-
dgtasersyd schrieb:
junta schrieb:
Und wie festgestellt, nützt dir ein fehlerfreier Quelltext nichts, wenn der Compiler ein fehlerhaftes Compilat erstellt.
Wie oft ist dir das schon mal passiert?
Mit dem Codegear RAD Studio 2007: Mindestens drei mal.
-
dgtasersyd schrieb:
Programme mit <10 Codezeilen scheinen fehlerfrei umsetzbar zu sein. Und Programme mit 11 Zeilen? Ich behaupte mal, bis 1000 Zeilen ist fehlerfreiheit gut machbar, wenn mans drauf anlegt.
Was hat das mit der Anzahl der Codezeilen zu tun? Ich kann ein Programm schreiben, das 10000mal "Hallo, Welt!" ausgibt (ja, ohne Schleife), das ist dann fehlerfrei. Andererseits kann es sein, dass ein Algorithmus in 10 Zeilen falsch ist, ohne dass es einer merkt. (Beispiel binäre Suche)
Wenn man dann das Programm ganz klar in Module mit <1k Zeilen unterteilt und diese zusammensetzt sollte das Endergebnis auch wieder fehlerfrei sein, wenn es nicht allzu viele Module sind.
Vielleicht setzt man sie ja falsch zusammen.
-
Was hat Fehlerfreiheit mit Quellcode zu tun? Ich finde nicht viel.
