Coverity bescheinigt Open-Source-Software eine gute Qualität

Die Qualität von Quellcode lässt sich anhand verschiedener Faktoren bestimmen. Sei es Kürze, Effizienz, Struktur oder eben auch Fehlerfreiheit. Diese Fehlerfreiheit kann man wiederum mit verschiedenen Werkzeugen messen. Eines dieser Werkzeuge ist Coverity.

Open-Source-Report 2012¶

Coverity 🇬🇧 ist eine Firma, die sich mit statischer Code-Analyse (siehe unten) beschäftigt. Seit 2008 wird mit Hilfe der Software „Coverity Scan“ ein jährlicher Bericht herausgegeben, der die Qualität (im Sinne von Fehlerfreiheit) von Open-Source-Software prüft. Diese Woche ist der Coverity Scan: 2012 Open Source Report 🇬🇧 erschienen, der auch als 61-seitiges PDF-Dokument 🇬🇧 vorliegt.

Der Test¶

Geprüft wurden verschiedene Open-Source-Projekte, wie z.B. der Linux Kernel, Apache oder PHP, aber auch kommerzielle Software von über 300 Coverity-Kunden wurde (anonymisiert) zum Vergleich herangezogen. Im Report für das Jahr 2012 wurden 118 Open-Source-Programme und 250 proprietäre Programme verglichen.

Als Ergebnis kam heraus, dass in den getesteten Open-Source-Projekten durchschnittlich 0,69 Fehlerstellen je 1000 Code-Zeilen gefunden wurden. Bei proprietären Programmen lag die Fehlerrate ähnlich bei 0,68 Fehlern je 1000 Code-Zeilen. Ein Wert unter 1,0 wird dabei allgemein als gut angesehen.

Aus der Code-Größe ließ sich ablesen, dass bei proprietären Programmen die Fehlerrate sinkt, je mehr Zeilen Code das Projekt besitzt. Bei Open-Source-Programmen war dies genau gegenteilig: ein größeres Programm bedeutete eine höhere Fehlerrate.

Als Grund für dieses Ergebnis gibt Coverity an, dass Open-Source-Programme vor allem am Anfang ihrer Entstehung viele Entwickler anziehen, die über den Code schauen. Je älter und größer ein Projekt aber werde, desto weniger Entwickler arbeiten aktiv daran und entsprechend schwerer würde die Verwaltung und Wartung des Codes werden.

Gelobt wurde vor allem die Qualität des Linux Kernels. Zitat: „We are happy to report that Linux continues to be a “model citizen” open source project for good software quality.“ Dieses Lob hat sich der Kernel verdient, da sich bei knapp 7,5 Millionen analysierter Code-Zeilen eine Fehlerrate von 0,66 ergab. In der zuletzt untersuchten Kernel-Version 3.8 lag die Fehlerrate sogar bei nur 0,59 Fehlern pro 1000 Code-Zeilen.

Hintergrund¶

Coverity zählt zu den Werkzeugen für eine statische Code-Analyse. Dies sind Programme, mit denen man ohne den Quellcode übersetzen (kompilieren) zu müssen, den Code anhand verschiedener Regeln (z.B. MISRA-C) prüft. Zu den Regeln zählen z.B. Speicherlecks, Zugriff außerhalb von definierten Speicherbereichen, toter Code (der nicht durchlaufen werden kann) und vieles mehr. Sehr viele große Projekte nutzen solche Analyse-Programme, um nicht offensichtliche und potentielle Fehler im Code zu finden und zu beseitigen.

Neben Coverity gibt es noch andere kommerzielle Programme, die Code analysieren und versuchen Fehler aufzudecken. Dazu zählen auch das wohl bekannteste Werkzeug Lint 🇬🇧, aber auch CodeSonar, die Axivion Bauhaus Suite und Klocwork Insight 🇬🇧.

Open-Source-Projekte können sich für einen Scan 🇬🇧 bei Coverity registrieren.

Links¶

Veröffentlicht von Dee | 10. Mai 2013 07:20 | Kategorie: Linux und Open Source | # Fehler im Artikel melden

borish	1 10. Mai 2013 15:18 MISRA-C ist ein Standard für die Autoindustrie. Mit Coverty hat das nichts zu tun. Coverty verwendet abstrakte Interpretation, um Fehler zu finden. Über die tatsächlich vorhandene Anzahl Fehler sagen obige Zahlen jedoch nur wenig aus, da nur ein kleiner Teil aller Fehler von einem automatischen Tool gefunden werden kann. Vergleichbares Beispiel: Die Rechtschreibkontrolle findet keine Fehler in einer Hausarbeit, diese kann aber dennoch fehlerhaft sein. Bauhaus dient zum Untersuchen der SW-Architektur, nicht zum Finden von Bugs. Ein weiteres Analystool ist Valgrind, mit dem Memory Leaks gefunden werden können.
katze_sonne	2 10. Mai 2013 20:47 @1: Also ich habe mir auch gerade nochmal den Wikipediaartikel zu MISRA-C durchgelesen. Danach verstehe ich das so, dass dieser Standard von der Autoindustrie für C entwickelt wurde. Und Coverity analysiert C-Code halt nach diesen Regeln... Sollte also doch stimmen. Natürlich ist der Test nur begrenzt aussagekräftig, aber wenn schon so eine automatische Analyse viele Fehler zum Vorschein bringt, ist normalerweise schon mit Problemen zu rechnen. Zu Valgrind: Ja, stimmt. Kenne ich nur zu gut, das Tool, ~~dürfen~~ müssen wir im Studium verwenden - aber macht ja auch Sinn und findet wirklich einige Dinge die man sonst übersehen hätte.
sephirot_1024	3 11. Mai 2013 13:34 @1: Coverity durchsucht ein C-Projekt unter anderen auch nach den MISRA Regeln, wenn der Anwender es wünscht, dass was im Artikel steht ist also vollkommen korrekt.
Dee	4 11. Mai 2013 18:35 @1: Da ich den Artikel geschrieben habe. Sowohl Coverty als auch LINT prüfen Code nach den MISRA-Regeln. Die Aussage "Bauhaus dient zum Untersuchen der SW-Architektur, nicht zum Finden von Bugs." ist auch nicht ganz korrekt. Von der Axivion-Webseite: "Stylechecks, Überprüfung von Coding Guidelines: Der mitgelieferte Standardsatz deckt Misra C 2004 und Misra C++ 2008 ab. Namensregeln können individuell konfiguriert werden. Darüber hinaus können Stylechecks individuell erstellt werden." Das sind also eher Stilfehler, die leichter zu Bugs führen. Die statische Analyse ist in großen Projekten (neben der dynamische Analyse) in meinen Augen unverzichtbar. Ich kann gar nicht zählen, wie viele Fehler dadurch bei uns schon gefunden wurden und nicht erst beim Anwender. Gruß Dee
borish	5 11. Mai 2013 22:43 MISRA-C ist eine Codierstandard, der in der Autoindustrie verwendet wird, um einigen der größten Probleme von C aus dem Weg zu gehen. MISRA-C verlangt dabei jedoch einige wesentliche Einschränkungen, so daß MISRA-C auch in der Autoindustrie nicht durchgängig befolgt wird. Für Projekte außerhalb der Autoindustrie ist MISRA-C weitgehend irrelevant. Deshalb wirkt die Erwähnung von MISRA-C bei einem Artikel über FOSS deplaciert. Es gibt sehr viele Tools, die die Einhaltung von Codierrichtlinien wie MISRA-C prüfen. Das sagt aber noch recht wenig über die Qualität des Codes aus. Deutlich tiefer geht eine Analyse mit Hilfe der abstrakten Interpretation. Code, in dem eine abstrakte Interpretation viele Fehler findet, wird eine geringe Qualität haben. Die Umkehrung gilt jedoch nicht. Denn nur eine kleine Klasse von Bugs kann durch eine statische Analyse gefunden werden. Das muß man bei der Interpretation obiger Ergebnisse berücksichtigen. Bugs werden durch eine ungünstige SW-Architektur oder durch Nichtbeachtung von Codierrichtlinien begünstigt, aber Bauhaus ist primar ein Tool zur Architekturanalyse.
katze_sonne	6 11. Mai 2013 23:30 @5: Hier wird mit MISRA-C nur ein bekanntes Beispiel genannt. Ob MISRA-C jetzt wirklich weitgehend irrelevant ist außerhalb der Autoindustrie, kann ich nicht beurteilen, aber es hat auch niemand gesagt, dass es überall relevant ist. Das war nur ein Beispiel zur Veranschaulichung. Deswegen ist das Beispiel im Artikel doch noch lange nicht deplaziert ☺ Aber trotzdem nochmal danke für deinen Kommentar (deine beiden Kommentare), denn jetzt habe ich zumindest schonmal eine bessere Vorstellung davon, was genau MISRA-C ist - vorher hatte ich den Wikipedia-Artikel nämlich nicht angeschaut ☺
auchfrager	7 12. Mai 2013 12:49 Ich lese als Laie nach einem "echo "7500*0.6" \| bc" die Zahl von 4500 Fehlern im Kernel und bin erstaunt, dass er dennoch funktioniert. Welche Informationen liefert diese Zahl ausserdem ?
timmie	8 12. Mai 2013 19:22 Hallo, was hat das mit Sicherheitstechnik zu tun? "Initiated in 2006 in collaboration with the US Department of Homeland Security" http://scan.coverity.com/
vokuit00	9 26. Juni 2013 08:29 Hallo, Coverity bietet aktuell keinen Check nach MISRA-C an. Es wird zwar darüber nachgedacht das zukünftig anzubieten, aber es gibt aktuell noch nichts. Wir nutzen die kaufversion von Coverity und hätten gerne den MISRA-C-Check. DIE MISRA-C-Regeln kommen zwar aus der Automobilindustrie werden heute aber im Umfeld von sicherheitsrelevanten C-Code genutzt weil die Norm IEC 65018 vorschreibt für Safety-Entwicklungen einen eingeschränkten Sprachumfang zu nutzen.