Was nützt es uns wenn irgendwelche Experten mitteilen das sie gut 1000 Fehler gefunden haben, aber nicht die exakten Stellen nennen damit man die Zahl um 1000 Fehler verringern kann.
Wirklich sinnvoll erscheint mir so eine Auswertung nur, wenn man hinterher eine Liste eine Liste online stellt in der alle Fehler und ihre Position veröffentlicht werden. z. B. Funktion X in Datei Y hat Fehler Z
Mit so einer Angabe sollte es relativ schnell möglich sein viele diese Fehler zu beheben. Wahrscheinlich sind es auch kleinere Fehler die man mit einem übersichtlichen Patch von wenigen Zeilen beheben kann.
Mit so einer Angabe ist es auch relativ schnell möglich pöse Exploits zu schreiben, dass sollte dir in dem Zusammenhang auch bewusst sein. Ich denke schon, dass diese Liste an die Kernel-Entwickler geschickt wurde.
Die müssen doch die Fehler nachweisen , wie glaubwürdig wären sie dan wenn, die die Fehler nicht "zeigen" bzw. auf die Fehler zuweisen. Ich würde denen,dann, nicht glauben. ;)
1) Die Automatischen Tools erkennen manche Codekonstrukte als Fehler die keine Fehler sind. 2) Man kann durch eine Fehlerbereinigung das Programm auch kaputter machen als es vorher war. 3) 1000 Fehler brauchen einige Zeit bis sie behoben sind, teilweise sind sicher Neuprogrammierungen von ganzen Modulen notwändig.
Es ist also unmöglich bei ständigem Feature-Zuwachs mit der Anzahl der Fehler runterzukommen. Dazu müsste man den Kern für ein Jahr Feature-freezen damit das erreicht werden kann.
Ich bin mir sicher, die Liste wird wieder an die Kernel-Entwickler geschickt damit man die kritischsten Fehler beheben kann.
Das es einige Male zum Fehlalarm kam kann schon sein, allerdings besteht auch die Möglichkeit, dass weitere 1000 Fehler übersehen wurden.
Die Idee mit dem Feature-freeze wäre nicht mal das schlimmste. Es ist besser langsam weiter zu machen und nächstes Jahr eine Null zu streichen, als durch lauter neue Patchs noch eine Null an den Fehlerzahl dran zu hängen.
Bei zwei Sachen sind wir uns wohl alle einig: So lange der Kernel von Menschen weiter entwickelt wird gibt es neue Fehler, Jeder behobene Fehler ist ein guter Fehler.
Von Boris Jakubith am Sa, 6. August 2005 um 19:59 #
Hi!
"O tempora, o mores!" bedeutet (in etwa) "Oh Zeit(en), oh Sitten", und beklagt einen mit der Zeit fortschreitenden Sittenverfall. Warum dieser Spruch hier angegeben wurde, und was er hier (in diesem Zusammenhang) bedeuten soll, ist mir allerdings (ebenfalls) schleierhaft...
> 1) Die Automatischen Tools erkennen manche Codekonstrukte als Fehler die keine Fehler sind.
Es hat sich als guter Programmierstil bewährt, den Code so zu schreiben, dass er nicht nur syntaktisch korrekt übersetzt wird, sondern auch keine "Falle" für sich einlesende Entwickler (dazu gehören AFAIK auch Suchtools aller Art) darstellt. Wir haben in der Vergangenheit unsere Sourcen so umgestellt, daß die Complier keie Warnungen mehr bringen. Rein subjektiv meinen wir damit auch eine höhere Stabilität erreicht zu haben. So manche Warnung scheint also berechtigt gewesen zu sein. Es war wesentlich einfacher, alle Warnungen zu beseitigen, als selbst nach möglichen Fehlern zu suchen.
> 2) Man kann durch eine Fehlerbereinigung das Programm auch kaputter machen als es vorher war.
Stimmt, aber die Warscheinlichkeit, dass es eine Verbesserung ist, ist deutlich höher. Man sollte nicht nur einfach "basteln" bis die Warnung weg ist, sondern auch mal über die Ursache nachdenken.
> 3) 1000 Fehler brauchen einige Zeit bis sie behoben sind, teilweise sind sicher Neuprogrammierungen von ganzen Modulen notwändig.
So gut, dass ein Tool die Struktur eines Moduls bewerten könnte, sind wir denn doch wohl noch nicht. Die hier angemerkten Fehler sind wohl eher in den Kategorien Parameterübergaben und Überprüfungen zu sehen.
Die absolute Quote AnzahlFehler zu AnzahlLinesOfCode ist ja durchaus auch besser geworden. Nur neue/zusätzliche Module bringen halt auch neuen Code mit neuen Fehlern.
Von Sebastian (-opitz.de.vu ^^) am Mo, 5. Juni 2006 um 09:40 #
Also. Ich weiss ja nicht, ob 17 fehler auf 100.000 Zeilen Code viel ist, aber ma ne andere Frage: Wie schreibt man so viel?, ich meine, bei 0,17 fehler pro 1000 zeilen sind das insgesamt ca. 5,9 millionen zeilen wenn es 1008 fehler gab.....
Wirklich sinnvoll erscheint mir so eine Auswertung nur, wenn man hinterher eine Liste eine Liste online stellt in der alle Fehler und ihre Position veröffentlicht werden. z. B. Funktion X in Datei Y hat Fehler Z
Mit so einer Angabe sollte es relativ schnell möglich sein viele diese Fehler zu beheben. Wahrscheinlich sind es auch kleinere Fehler die man mit einem übersichtlichen Patch von wenigen Zeilen beheben kann.
mfg Razdan
2) Man kann durch eine Fehlerbereinigung das Programm auch kaputter machen als es vorher war.
3) 1000 Fehler brauchen einige Zeit bis sie behoben sind, teilweise sind sicher Neuprogrammierungen von ganzen Modulen notwändig.
Es ist also unmöglich bei ständigem Feature-Zuwachs mit der Anzahl der Fehler runterzukommen.
Dazu müsste man den Kern für ein Jahr Feature-freezen damit das erreicht werden kann.
Ich bin mir sicher, die Liste wird wieder an die Kernel-Entwickler geschickt damit man die kritischsten Fehler beheben kann.
Die Idee mit dem Feature-freeze wäre nicht mal das schlimmste. Es ist besser langsam weiter zu machen und nächstes Jahr eine Null zu streichen, als durch lauter neue Patchs noch eine Null an den Fehlerzahl dran zu hängen.
Bei zwei Sachen sind wir uns wohl alle einig:
So lange der Kernel von Menschen weiter entwickelt wird gibt es neue Fehler,
Jeder behobene Fehler ist ein guter Fehler.
"notwändig"?
O tempora, o mores!
O tempora, o mores!
??????
Ich verstehe dich noch weniger als notwändig ...
"O tempora, o mores!" bedeutet (in etwa) "Oh Zeit(en), oh Sitten", und beklagt einen mit der Zeit fortschreitenden Sittenverfall. Warum dieser Spruch hier angegeben wurde, und was er hier (in diesem Zusammenhang) bedeuten soll, ist mir allerdings (ebenfalls) schleierhaft...
Ich hoffe nur, daß einige hier nicht so coden wie sie schreiben, denn das würde die Fehlerzahl im Kernel vervielfachen...
Es hat sich als guter Programmierstil bewährt, den Code so zu schreiben, dass er nicht nur syntaktisch korrekt übersetzt wird, sondern auch keine "Falle" für sich einlesende Entwickler (dazu gehören AFAIK auch Suchtools aller Art) darstellt.
Wir haben in der Vergangenheit unsere Sourcen so umgestellt, daß die Complier keie Warnungen mehr bringen. Rein subjektiv meinen wir damit auch eine höhere Stabilität erreicht zu haben. So manche Warnung scheint also berechtigt gewesen zu sein. Es war wesentlich einfacher, alle Warnungen zu beseitigen, als selbst nach möglichen Fehlern zu suchen.
> 2) Man kann durch eine Fehlerbereinigung das Programm auch kaputter machen als es vorher war.
Stimmt, aber die Warscheinlichkeit, dass es eine Verbesserung ist, ist deutlich höher. Man sollte nicht nur einfach "basteln" bis die Warnung weg ist, sondern auch mal über die Ursache nachdenken.
> 3) 1000 Fehler brauchen einige Zeit bis sie behoben sind, teilweise sind sicher Neuprogrammierungen von ganzen Modulen notwändig.
So gut, dass ein Tool die Struktur eines Moduls bewerten könnte, sind wir denn doch wohl noch nicht. Die hier angemerkten Fehler sind wohl eher in den Kategorien Parameterübergaben und Überprüfungen zu sehen.
Die absolute Quote AnzahlFehler zu AnzahlLinesOfCode ist ja durchaus auch besser geworden. Nur neue/zusätzliche Module bringen halt auch neuen Code mit neuen Fehlern.
Ciao,
H.
Einmal reicht auch.