Einblick in die statische Code-Analyse:
Auf verschlungenen Pfaden
Fortsetzung des Artikels von Teil 3
Optimierung der Parameter
Bei CodeSonar hat der Endnutzer Zugriff auf viele der für die Steuerung der Analysealgorithmen verwendeten Parameter. So wurde im vorhergehenden Abschnitt beispielsweise erläutert, wie die Analyse die für die Untersuchung jedes einzelnen Ablaufs verfügbare Zeit einschränkt. Dieser Parameter lässt sich durch einfaches Editieren der textuellen Konfigurationsdatei ändern. Auf ähnliche Weise kann das Erstellen von Warnmeldungen aktiviert oder deaktiviert werden; sogar die Durchführung leichter Prozesse an Fehlern bei deren Generierung ist problemlos möglich. Alle Warnungen, die in der Datei „Robert.c“ gefunden werden, lassen sich etwa dem Benutzer Bob zuordnen.
Für Benutzer ist es normal, dass sie Domain-spezifische Regeln für ihre Codebasis haben. Viele davon sind spezielle Fälle allgemeiner Regeln oder ähneln anderweitig den Arten von Eigenschaften, die CodeSonar erkennen kann. Viele der vorhandenen Prüfprogramme sind erweiterbar, sodass sie bei Domain-spezifischen Regeln wirksam greifen. Wenn beispielweise eine Anwendung über eine endliche Ressource verfügt, die über Funktionen verwaltet wird, die ihr Instanzen dieser Ressource zuweisen oder freigeben, dann ist es problemlos möglich, CodeSonar die Namen dieser Funktionen mitzuteilen. Dadurch sind eingebaute Kontrollen wie jene, die Lecks oder Use-after-free-Fehler erkennen, funktionsfähig.
APIs für individuelle Prüfprogramme
Ähnelt eine kundenspezifische Prüfung keiner vorhandenen, muss das API von CodeSonar so abgeändert werden, dass es diese schreibt. Dafür gibt es zwei Möglichkeiten: Die einfachste Variante ist, dass der Nutzer den Code mit Aufrufen an die Funktionen von CodeSonar kommentiert, die die Analyse über einfache Eigenschaften informieren. Das Schreiben von Prüfungen auf diese Art funktioniert sehr ähnlich wie das Schreiben dynamischer Prüfungen für dieselbe Eigenschaft. Angenommen wird etwa eine Regel, die das Aufrufen einer Funktion verbietet, deren Signatur go(int i) mit einem negativem Parameter ist. Das kann durch Hinzufügen einer einzigen Zeile zum Funktionsrumpf passieren, die einer Behauptung gleicht:
csonar_trigger(i, „<“, 0, „Parameter to go() is negative“);
Möchte der Nutzer dem Code keine derartigen Anmerkungen hinzufügen, gibt es einen aspektorientierten ähnlichen Mechanismus, über den die Kommentare als separate Einträge hinzugefügt werden können.
Dieses API ist zwar einfach, aber recht leistungsfähig. Neben Prüfungen wie der eingangs beschriebenen ermöglicht es das Schreiben von Typestate-Prüfungen, die etwa den Zustands eines Objekts verfolgen und Warnungen generieren, wenn ein unzulässiger Status möglich ist.
Reicht das API nicht aus, kann sich der Nutzer bei CodeSonar auf die bereits vorhandenen Umgehungen des Programms stützen. Zum Einsatz kommt hier ein Modell mit einem besucherähnlichen Muster. So ist es möglich, die Überprüfung einer Eigenschaft einer Funktion als Rückruf zu registrieren, der aktiviert wird, wenn die Analyse diese Funktion während ihrer regulären Analyse überprüft. Über dieses API steht das gesamte Programmmodell einschließlich aller bereits beschriebenen Zwischendarstellungen zur Verfügung. Sie ist in verschiedenen Sprachen verfügbar, darunter C, C++, Python, Java, C# und Scheme.
Der Nutzer bestimmt die Arbeitsweise
Fortgeschrittene Analysewerkzeuge sind ausgefeilte, deutlich leistungsfähigere Tools als die Werkzeuge der ersten Generation wie Lint und dessen Ableger. Als Haupteigenschaften sind sie interprozedural, pfadempfindlich und für ganze Programme nutzbar. Die von ihnen verwendeten Algorithmen zielen darauf ab, die interessanten und schädlichen Fehler mit einer angemessenen Quote an falsch-positiven Treffern zu finden, ohne dabei übermäßig viele Ressourcen zu nutzen – auch bei Programmen mit Millionen an Codezeilen. Mit der randomisierten Pfadüberprüfung lassen sich die untereinander in Konkurrenz stehenden Belange von Gründlichkeit und Skalierbarkeit gegeneinander abwägen. Eine Optimierung dieser Algorithmen auf besondere Anforderungen, sogar das Schreiben von Prüfprogrammen für Domain-spezifische Eigenschaften, ist möglich.
Der Autor:
Jobangebote+ passend zum Thema
| Dr. Paul Anderson |
|---|
| leitet die Entwicklungsabteilung bei GrammaTech (USA), einem Hersteller von Statische-Code-Analyse-Tools. Dr. Anderson hat über 20 Jahre Erfahrung in der Entwicklung von Statische-Analyse-Werkzeugen und automatisierten Test Tools. Er besitzt einen Hochschulabschluss (Bachelor of Science) des Kings College, Universität London, und einen Doktortitel der City-Universität London. Seine Arbeit findet Erwähnung in zahlreichen Artikeln, Buchkapiteln und auf internationalen Konferenzen. |
sales@grammatech.com
- Auf verschlungenen Pfaden
- Einfache syntaktische Abfragen
- Wandeln auf unbekannten Pfaden
- Optimierung der Parameter
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Unit-Tests
In der Theorie großartig, aber …
Betriebssysteme
Kostenlos - bis das Geschäft läuft
Fünf Ursachen für unliebsame Firmware-Fehler
Rezepte fürs Bugfixing
Software-Entwicklung
Vorgetäuschte Hardware
Software-Entwicklung:
Wo kommen bloß die Fehler her?
