Fehlersuche, undefiniertes Verhalten und sicheres C

Warnungen geben dir die Gelegenheit, einen Defekt zu beheben, bevor eine Eingabe ihn auslöst. Ein Fehler verhindert eine erfolgreiche Erstellung. Eine Warnung lässt die Erstellung weiterlaufen, meldet aber etwas, das du verstehen musst: verdächtigen gültigen Code, mögliches undefiniertes Verhalten oder einen Verstoß gegen eine Sprachregel, den der Compiler akzeptiert.

Nützliche Prüfungen auswählen

Starte GCC oder Clang mit einer ausdrücklich gewählten Sprachversion und einer breiten Auswahl an Warnungen:

clang -std=c17 -Wall -Wextra -Wpedantic -g program.c -o program

-Wall aktiviert viele gängige Prüfungen, nicht alle Warnungen. -Wextra ergänzt weitere, darunter Vergleiche zwischen vorzeichenbehafteten und vorzeichenlosen Werten in C. -Wpedantic meldet viele Abweichungen vom gewählten ISO-Standard; es ist kein vollständiger Test der Standardkonformität. /W4 von MSVC erfüllt unter Windows einen ähnlichen Zweck.

Ergänze Prüfungen, die zu den Risiken in deinem Code passen:

Zum Beispiel verwirft double price = 3.7; int whole = price; den Nachkommateil. -Wconversion macht diese Umwandlung sichtbar. Wenn das Abschneiden beabsichtigt und der Wert darstellbar ist, drückt (int)price diese Entscheidung aus. Wenn der Nachkommateil wichtig ist, behalte einen Gleitkommatyp. Für das Runden auf die nächste Ganzzahl erfüllt lround aus <math.h> eine andere Aufgabe als eine explizite Typumwandlung.

Die erste hilfreiche Meldung lesen

Eine Compilermeldung nennt normalerweise eine Stelle im Quelltext, eine Meldung und die Warnoption. Ein Zirkumflex markiert den betreffenden Ausdruck; nachfolgende Hinweise können eine Deklaration nennen oder eine Korrektur vorschlagen. Lies die gesamte Gruppe. Wenn ein Syntaxfehler viele spätere Meldungen verursacht, behebe den ersten Fehler und kompiliere erneut, bevor du den übrigen nachgehst.

Angenommen, ein Programm enthält diese drei Zeilen, wobei average als double deklariert ist:

if (count = 0) { /* report no data */ }
printf("%d\n", average);
int unused;

Die Zuweisung in der Bedingung setzt count auf null und macht die Bedingung damit falsch. War ein Vergleich beabsichtigt, verwende count == 0. Zusätzliche Klammern um die Zuweisung können eine Warnung unterdrücken, während der Programmfehler bestehen bleibt.

Das Format %d erwartet einen int, aber das Argument ist ein double. Verwende %f; ein unpassendes Format ist undefiniertes Verhalten und keine Aufforderung, den Wert umzuwandeln. Lösche die ungenutzte Deklaration, wenn sie keinen Zweck erfüllt. Das sind drei unterschiedliche Ursachen, die jeweils eine eigene Korrektur brauchen.

Den Hinweisen folgen

Achte besonders auf nicht initialisierte Werte, fehlende Rückgaben, zurückgegebene Adressen lokaler Variablen und sizeof bei Arrayparametern. Durch eine fehlende Headerdatei kann eine Funktion undeklariert bleiben; aktuelle Versionen von GCC und Clang weisen dies standardmäßig zurück. Füge nicht einfach eine explizite Typumwandlung hinzu, damit eine Meldung verschwindet. Erkläre zuerst, welche Typen und Werte beabsichtigt sind, und bringe diese Absicht dann im Code zum Ausdruck.

Ein Programm ohne Warnungen kann trotzdem eine fehlerhafte Schleifenbedingung oder einen fehlerhaften Index aus einer Eingabe enthalten. Manche Warnungen hängen außerdem von Optimierung und Datenflussanalyse ab, und verschiedene Compiler erkennen unterschiedliche Fälle. Lass die Warnungen bei gewöhnlichen Erstellungsvorgängen aktiviert und untersuche anschließend das Verhalten zur Laufzeit mit dem Debugger und Testwerkzeugen.

Derselbe Quelltext kann für eine einfache Untersuchung, intensive Tests oder eine effiziente Veröffentlichung erstellt werden. Die Erstellungseinstellungen bestimmen, welche Informationen du sehen kannst und welche zusätzlichen Prüfungen ausgeführt werden. Gib jedem Build einen klaren Zweck.

Quelltextinformationen erhalten

Die Option -g ergänzt Namen, Typen und Zuordnungen zwischen Maschinenbefehlen und Quelltextzeilen. Damit kann ein Debugger deinen Code anzeigen, und Sanitizerberichte können Stellen im Quelltext nennen. Die Option aktiviert weder Laufzeitprüfungen noch deaktiviert sie die Optimierung. Ohne Debuginformationen können manche Funktionsnamen verfügbar bleiben, aber Quelltextzeilen und lokale Variablen lassen sich viel schwerer ermitteln.

Die Optimierung verändert, wie eng die Ausführung der Reihenfolge im Quelltext folgt:

Bei einer Debuggersitzung mit optimiertem Code können Zeilen übersprungen werden oder eine Variable als „“ angezeigt werden. Der Compiler hat das Verhalten von definiertem Code erhalten, muss aber nicht mehr jeden Zwischenwert aus dem Quelltext beibehalten. -O0 übersetzt nicht buchstäblich jede C-Zeile in genau einen Maschinenbefehl.

Für den jeweiligen Zweck erstellen

Ein einfacher Debug-Befehl lautet:

gcc -std=c17 -Wall -Wextra -Wpedantic -g -O0 program.c -o program-debug

Ein Test-Build ergänzt Sanitizer. Ein Release-Build verwendet gewöhnlich -O2 und kann NDEBUG definieren, um Zusicherungen zu entfernen. Gewöhnliche Eingabeprüfungen und die Fehlerbehandlung müssen aktiv bleiben, wenn Zusicherungen entfallen. Teste auch die Release-Konfiguration: Ein Problem, das nur bei Optimierung sichtbar wird, ist ein starkes Anzeichen dafür, nach undefiniertem Verhalten zu suchen, einschließlich Lesezugriffen auf nicht initialisierte Werte und Überläufen bei vorzeichenbehafteten Ganzzahlen.

Halte gemeinsam verwendete Optionen in einem Makefile oder einer anderen Erstellungskonfiguration fest. Getrennte Ausgabenamen verhindern, dass du versehentlich eine alte ausführbare Release-Datei startest, während du gerade bearbeiteten Quelltext untersuchst. Erstelle nach jeder Quelltextänderung die ausführbare Datei erneut, die du ausführen möchtest.

Analyse und Härtung ergänzen

Die statische Analyse verfolgt mögliche Pfade durch den Quelltext, ohne das Programm auszuführen. Probiere gcc -fanalyzer oder clang --analyze; scan-build, clang-tidy und cppcheck bieten weitere Analyseverfahren. Ein Analysewerkzeug kann bemerken, dass ein Fehlerzweig einen Zeiger zweimal freigibt, selbst wenn deine Tests diesen Zweig nie durchlaufen. Prüfe seine Begründung: Die Analyse möglicher Pfade kann Fehlalarme erzeugen.

Die dynamische Analyse prüft die tatsächliche Ausführung. Sanitizer und Valgrind sehen nur die Pfade, die du ausführst, sodass ihre Abdeckung von deinen Eingaben abhängt. Kombiniere beide Arten der Analyse.

Die Härtung für die Veröffentlichung begrenzt den Schaden durch verbleibende Defekte. -fstack-protector-strong fügt in ausgewählten Stackframes Prüfungen ein, die viele Überschreibungen erkennen. Auf unterstützten Systemen ergänzt _FORTIFY_SOURCE Prüfungen bei Bibliotheksaufrufen, wenn sich Objektgrößen bestimmen lassen. Es benötigt Optimierung; Stufe 2 ist üblich, während Stufe 3 eine geeignete Unterstützung durch Compiler und C-Bibliothek voraussetzt. Dies sind Plattformfunktionen, keine Garantien von ISO C.

Ein gehärtetes Programm kann anhalten, wenn es eine Beschädigung erkennt. Die ungültige Operation muss trotzdem im Quelltext korrigiert werden; eine Änderung der Release-Optionen kann keine Schleife korrigieren, die außerhalb der Speichergrenzen zugreift.

Ein Fehlverhalten ist das Verhalten, das du beobachtest: ein Absturz, eine falsche Summe oder eine Ausgabe, die nie erscheint. Ein Programmfehler ist der Fehler, der es verursacht hat. Wenn du beides auseinanderhältst, änderst du nicht vorschnell die Absturzzeile, bevor du herausgefunden hast, wie das Programm dorthin gelangt ist.

Das Fehlverhalten reproduzierbar machen

Halte den Befehl, die Eingabe, die Erstellungsoptionen, das erwartete und das tatsächliche Ergebnis fest. Lass die fehlerauslösende Eingabe unverändert, während du experimentierst. Schlägt ein Programm nur bei einer Datei fehl, speichere diese Datei, bevor du sie bearbeitest. Durch die Reproduktion kannst du beurteilen, ob eine vorgeschlagene Korrektur funktioniert.

Verkleinere als Nächstes das Beispiel, ohne das Fehlverhalten zu beseitigen. Entferne nicht benötigte Datensätze oder Code und führe das Programm erneut aus. Angenommen, ein Datensatz unter 1.000 löst unabhängig von den anderen einen Absturz aus. Durch das Prüfen von Hälften lässt er sich in etwa 10 Runden finden. Schlägt keine der beiden Hälften allein fehl, benötigt das Fehlverhalten möglicherweise eine Folge von Datensätzen oder einen zuvor aufgebauten Zustand. Behalte diese Folge bei und entferne kleinere Teile darum herum. Halbieren hilft nur, wenn die verbleibende Eingabe die Ursache weiterhin auslöst.

Eine prüfbare Frage stellen

Ein leeres Feld in einer minimierten Datei legt eine Hypothese nahe: „Der Parser verwendet das Feld, bevor er prüft, ob es existiert.“ Prüfe das mit einer kleinen Eingabe, die ein leeres Feld enthält. Untersuche den zurückgegebenen Zeiger oder ergänze eine gezielte Prüfung. Ändere jeweils nur eine Sache; wenn du Parser, Puffergröße und Eingabe gleichzeitig änderst, zeigt ein Erfolg nicht, welche Änderung entscheidend war.

Behebe den Regelverstoß, führe das minimierte Beispiel erneut aus und danach die ursprüngliche Eingabe und die vorhandenen Tests. Speichere den Auslöser als Regressionstest, damit eine spätere Änderung nicht unbemerkt dasselbe Fehlverhalten zurückbringen kann.

Den Stopp deuten

„Segmentation fault“ meldet gewöhnlich SIGSEGV: Das System hat einen ungültigen Speicherzugriff gestoppt. Ein Nullzeiger, ein Zeiger auf freigegebenen Speicher oder eine Adresse außerhalb des zulässigen Bereichs ist eine häufige Ursache. Ein ungültiger Zugriff kann auch ohne unmittelbaren Absturz bleiben, sodass das Ausbleiben einer Meldung allein wenig aussagt.

„Aborted“ meldet häufig SIGABRT, das durch abort() ausgelöst wird. Eine fehlgeschlagene Zusicherung oder eine Bibliotheksprüfung, die eine Beschädigung des Heaps erkennt, kann dies verursachen. In bash sind übliche Signal-Rückgabestatus 139 für SIGSEGV und 134 für SIGABRT; diese Zahlen sind Shell-Konventionen und keine C-Rückgabewerte, die dein Programm verwenden muss.

Beobachten, ohne Ausgaben zu verlieren

Eine kurze Diagnoseausgabe kann den ersten falschen Wert aufdecken:

fprintf(stderr, "index=%zu total=%d\n", index, total);

Beschriftungen machen die Ausgabe lesbar, wenn dieselbe Zeile viele Male ausgeführt wird. stderr ist für Diagnosemeldungen nützlich, weil es nicht vollständig gepuffert ist; stdout ist bei Umleitung in eine Datei oder Pipe normalerweise vollständig gepuffert, sodass bei einem Absturz ausstehende Ausgaben verloren gehen können. Entferne vorübergehende Ausgaben nach der Korrektur.

Erkläre eine verdächtige Funktion Zeile für Zeile laut. Diese Gummientenmethode zwingt dich, jede Operation mit dem beabsichtigten Verhalten abzugleichen. Wenn sich ein Programmfehler verändert, sobald du Ausgaben hinzufügst oder die Optimierung änderst, untersuche mit Sanitizern, ob undefiniertes Verhalten vorliegt. Ein Array so lange zu vergrößern, bis ein Absturz verschwindet, kann einen ungültigen Index verbergen, ohne ihn zu korrigieren.

Mit einem Debugger kannst du ein laufendes Programm anhalten und die Werte untersuchen, die sein Verhalten erklären. Verwende GDB auf vielen Linux-Systemen oder LLDB unter macOS. Die Debugger-Schaltflächen in Entwicklungsumgebungen beruhen auf denselben Ideen: anhalten, ausführen, untersuchen und schrittweise weitergehen.

Mit der richtigen ausführbaren Datei beginnen

Kompiliere mit -g -O0 und öffne das Ergebnis dann mit gdb ./program oder lldb ./program. An der Eingabeaufforderung startet run records.txt 3 das Programm mit zwei Argumenten. In GDB leitet run < input.txt die Standardeingabe um; in LLDB verwendest du process launch -i input.txt. Mit quit beendest du den Debugger.

Setze vor der Ausführung einen Haltepunkt. break main in GDB und b main in LLDB halten am Anfang von main an. Beide akzeptieren eine Datei- und Zeilenangabe wie b program.c:12. Vollständige LLDB-Befehle sind unter anderem breakpoint set --name main und breakpoint set --file program.c --line 12.

Ein Haltepunkt hält normalerweise an, bevor die angegebene Quelltextanweisung ausgeführt wird. Weist die ausgewählte Zeile einen Wert zu, gib ihn nach der Ausführung der Zeile aus, um den neuen Wert zu untersuchen. Erstelle das Programm nach Änderungen am Quelltext erneut: Der Debugger führt Maschinencode aus, nicht den Text in deinem Editor.

Die Art des Weitergehens wählen

Andere Haltepunkte können next oder finish unterbrechen. Verwende next für einen Bibliotheksaufruf, den du nicht untersuchen musst. Gehst du in unerwünschten Code hinein, kehrst du mit finish zum Aufrufer zurück.

Eine Schleife Durchlauf für Durchlauf untersuchen

Betrachte eine mit null initialisierte Summe und dieses Array:

int a[5] = {4, 8, 15, 16, 23};
for (int i = 0; i <= 5; ++i) {
    sum += a[i];
}

Halte im Schleifenrumpf an und gib i und sum vor der Addition aus. Nach den ersten fünf Additionen lauten die Zwischensummen 4, 12, 27, 43 und 66. Beim nächsten Halt gilt i == 5, aber die gültigen Indizes enden bei 4. Du hast den zusätzlichen Durchlauf gefunden, ohne das ungültige Element lesen zu müssen. Ändere die Bedingung in i < 5, erstelle das Programm erneut und führe es wieder aus.

print expr oder p expr wertet in beiden Debuggern einen Ausdruck aus. Beginne mit sicheren Abfragen wie p i und p sum; ein Debuggerausdruck, der einen ungültigen Zeiger dereferenziert, kann selbst einen ungültigen Lesezugriff versuchen. display i in GDB wiederholt die Ausgabe bei jedem Halt. info locals in GDB und frame variable in LLDB zeigen lokale Variablen. Für fünf gültige Elemente über ptr verwendest du p *ptr@5 in GDB oder parray 5 ptr in LLDB.

Du kannst eine Hypothese prüfen, indem du einen Wert bei angehaltenem Programm änderst: GDB akzeptiert set var i = 4, LLDB akzeptiert expr i = 4. Das ändert einen Programmlauf, nicht den Quelltext. Zur Verwaltung der Haltepunkte verwendest du info breakpoints und delete 1 in GDB oder breakpoint list und breakpoint delete 1 in LLDB.

Ein Absturz innerhalb einer Bibliothek beginnt oft mit einem ungültigen Argument aus deinem eigenen Code. Der Aufrufstapel zeigt die aktiven Funktionsaufrufe. Nutze ihn, um von der Stelle des Halts zum Aufrufer zu gelangen, dessen Werte du erklären kannst.

Stackframes vom aktuellen Aufruf aus rückwärts lesen

Gib in einem der beiden Debugger bt ein. Stackframe #0 ist der innerste aktive Aufruf; höhere Stackframe-Nummern bezeichnen dessen Aufrufer. Ein Stackframe zeigt den Ausführungskontext der Funktion, einschließlich verfügbarer Argumente und lokaler Variablen. Durch Optimierung können einige dieser Informationen entfallen.

Angenommen, find_name(2) findet keinen passenden Eintrag und der Aufrufer führt Folgendes aus:

const char *name = find_name(2);
printf("%zu\n", strlen(name));

Der Halt kann innerhalb von strlen liegen. Suche in bt den ersten Stackframe, der zu deinem Code gehört. Ist es Stackframe 1, wähle ihn mit frame 1 in GDB oder frame select 1 in LLDB aus. Gib name aus. Ein Nullwert erklärt, warum die Zeichenkettenoperation fehlgeschlagen ist. Der Aufrufer muss den fehlenden Namen behandeln, bevor er strlen aufruft; eine Änderung der Bibliothek kann das Argument nicht korrigieren.

Mit up und down bewegst du dich zwischen Aufrufern und aufgerufenen Funktionen. Die Auswahl eines Stackframes ändert, was der Debugger anzeigt und auf welche lokalen Variablen sich ein Ausdruck bezieht. Sie setzt weder die Ausführung fort noch macht sie einen Aufruf rückgängig.

Anhalten, wenn sich ein Wert ändert

Ein Haltepunkt fragt: „Was geschieht an dieser Stelle?“ Ein Datenhaltepunkt fragt: „Welche Operation ändert diesen Wert?“ Wird eine gespeicherte Anzahl lange vor einem Absturz falsch, halte an, während die Anzahl im Gültigkeitsbereich ist, und verwende:

GDB:  watch count
LLDB: watchpoint set variable count

Fahre fort, bis der Debugger bei einer Änderung anhält. Untersuche den alten und den neuen Wert sowie die Quelltextstelle der schreibenden Anweisung. Eine Änderung kann zulässig sein, vergleiche sie also mit der Regel der Datenstruktur. Die Hardware bietet nur wenige Datenhaltepunkte; auf x86-64 sind vier üblich. Der Speicher einer lokalen Variablen ist nur sinnvoll nutzbar, solange ihre Funktion aktiv ist.

Für einen bekannten späten Durchlauf verwende einen bedingten Haltepunkt. break 20 if i == 999 in GDB hält in Zeile 20 nur an, wenn die Bedingung erfüllt ist. Das entsprechende Kommando in LLDB lautet breakpoint set --line 20 --condition 'i == 999'. Das erspart Hunderte manuelle Schritte.

Einen gespeicherten Absturz untersuchen

Ein Speicherabbild hält den Zustand eines abgestürzten Prozesses fest. Wo Speicherabbilder aktiviert sind, erlaubt ulimit -c unlimited sie für Programme, die aus dieser Shell gestartet werden. Öffne ein gespeichertes Abbild mit gdb ./program core oder lldb ./program -c core und verwende dabei die ausführbare Datei, die es erzeugt hat. Systemrichtlinien bestimmen, ob und wo ein Abbild gespeichert wird; Linux-Systeme mit systemd können es über coredumpctl verwalten.

Führe bt aus, wähle deinen Stackframe und untersuche Werte wie bei einem aktuellen Absturz. Mit dem Abbild lässt sich das Programm nicht fortsetzen. Wenn malloc oder free eine Beschädigung erkennt, kann der ursprüngliche fehlerhafte Schreibzugriff in diesem Aufrufstapel fehlen. Reproduziere den Fehler mit AddressSanitizer, um näher an diesem Schreibzugriff anzuhalten. Sieht ein lokaler Wert beliebig aus, prüfe, ob die Ausführung seinen Initialisierer bereits erreicht hat, bevor du den Debugger verantwortlich machst.

Undefiniertes Verhalten, kurz UB, bedeutet, dass der C-Standard keine Anforderungen daran stellt, was nach einer ungültigen Operation geschieht. Er verspricht weder eine Ausnahme noch eine hilfreiche Fehlermeldung oder einen vorhersagbaren Wert durch Wraparound. Ein Programm kann abstürzen, Daten beschädigen, eine plausibel wirkende Antwort ausgeben oder scheinbar funktionieren.

Drei Arten von Verhalten unterscheiden

Implementierungsdefiniertes Verhalten kann gezielt genutzt werden, wenn die dokumentierte Plattform Teil des Programmentwurfs ist. Für portablen Code solltest du nicht annehmen, dass alle Implementierungen dieselbe Wahl treffen. Auch nicht spezifiziertes Verhalten ist gültig: f(a(), b()) kann jeden der beiden unabhängigen Aufrufe zuerst auswerten. Schreibe Code, der bei dieser erlaubten Abweichung korrekt bleibt. Die Bitbreite von int und in C17 die Rechtsverschiebung einer negativen vorzeichenbehafteten Ganzzahl sind weitere plattformabhängige Entscheidungen.

Warum Optimierung Programmfehler sichtbar macht

C überlässt die Prüfung von Arraygrenzen und Additionen vorzeichenbehafteter Zahlen dem Programmierer. Der Compiler darf unter der Annahme optimieren, dass das Programm die Sprachregeln befolgt. Ein versuchter Überlaufdetektor kann genau gegen die Regel verstoßen, die er prüfen soll:

int will_overflow(int x) {
    return x + 1 < x;
}

Für jedes x, bei dem die vorzeichenbehaftete Addition definiert ist, ist x + 1 größer als x. Der Compiler kann das Ergebnis daher durch null ersetzen. Bei INT_MAX ist die Addition UB, sodass der Compiler dem Aufrufer kein Ergebnis durch Wraparound schuldet. Eine andere Antwort in einem nicht optimierten Build macht dies nicht zu einem gültigen Test.

Der sichere Test erfolgt vor der Operation:

if (x == INT_MAX) {
    /* handle overflow */
} else {
    ++x;
}

Verwende <limits.h> für die Schranken der Implementierung. Ein fest im Code angegebener Höchstwert setzt eine bestimmte Bitbreite des Typs voraus; das Makro benennt die tatsächliche Schranke.

Vor der ersten Verwendung prüfen

Diese Reihenfolge ist auch für Zeiger entscheidend:

if (p == NULL) {
    return -1;
}
int v = *p;

Werden diese Anweisungen vertauscht, kann ein Nullzeiger vor der Schutzprüfung dereferenziert werden. Sobald der Code p dereferenziert, kann ein Optimierer folgern, dass für einen definierten Pfad bereits gelten muss, dass p kein Nullzeiger ist, und eine spätere Nullprüfung entfernen.

Das Ändern von Optionen, das Hinzufügen einer Ausgabe oder das Verschieben einer Variablen kann das sichtbare Symptom von UB verändern. Ein erfolgreicher Lauf zeigt nur, was dieser Build bei dieser Eingabe getan hat. Um den Code zu korrigieren, finde heraus, welche Operation keine definierte Bedeutung hat und welche Bedingung vorher erfüllt sein muss. Warnungen können einige Fälle erkennen; statische Analyse kann mögliche Pfade untersuchen; ASan und UBSan prüfen viele ausgeführte Operationen. Programmierregeln liefern die entsprechenden Muster für den Quelltext, etwa einen Index oder eine arithmetische Schranke vor der Verwendung zu prüfen.

Eine arithmetische Operation kann fehlschlagen, bevor du ihr Ergebnis untersuchen kannst. Prüfe die Operanden, solange ihre Werte noch gültig sind, und kenne den Typ, in dem jede Operation ausgeführt wird.

Schranken vorzeichenbehafteter und vorzeichenloser Typen

Ein Überlauf bei vorzeichenbehafteten Ganzzahlen ist undefiniert. Bei einem int mit 32 Bit ist INT_MAX gleich 2.147.483.647; die Addition von eins ist kein portabler Weg, eine negative Zahl zu erhalten. Auch INT_MIN / -1, -INT_MIN und eine zu große Multiplikation schlagen fehl, wenn das mathematische Ergebnis nicht darstellbar ist.

Vorzeichenlose Arithmetik führt innerhalb des Wertebereichs ihres Typs zu Wraparound. Für einen unsigned int mit 32 Bit ist UINT_MAX + 1u gleich null und 0u - 1u gleich 4.294.967.295. Das ist definiert, kann aber dennoch eine Größenberechnung verfälschen. Eine rückwärts laufende Schleife mit einer vorzeichenlosen Variablen und i >= 0 erreicht nie einen negativen Wert zum Anhalten.

Prüfe vor einer allgemeinen Addition vorzeichenbehafteter Zahlen:

if ((b > 0 && a > INT_MAX - b) ||
    (b < 0 && a < INT_MIN - b)) {
    /* report overflow */
} else {
    result = a + b;
}

Die in diesen Prüfungen verwendeten Subtraktionen bleiben im Wertebereich, weil jede durch das Vorzeichen von b abgesichert ist. Erst die Summe zu berechnen und sie dann zu vergleichen, ist zu spät. Ein breiterer Typ hilft nur, wenn er jedes Zwischenergebnis aufnehmen kann: Konvertiere einen Operanden vor der Operation. C23 bietet ckd_add in <stdckdint.h>; GCC und Clang bieten __builtin_add_overflow.

Division, Bitverschiebungen und Typumwandlungen

Lehne null vor einer Ganzzahldivision oder Restbildung ab. Lehne auch die Division des vorzeichenbehafteten Minimums durch minus eins ab, wenn das Ergebnis nicht darstellbar ist. Gleitkommasysteme nach IEEE 754 erzeugen bei Division durch null häufig unendlich oder NaN, sodass sich ungültige numerische Ergebnisse ohne eine Abbruchreaktion wie bei Ganzzahlen ausbreiten können.

Verwende für Bitoperationen vorzeichenlose Operanden. Die Verschiebungsweite muss nicht negativ und kleiner als die Bitbreite des erweiterten linken Operanden sein. Bei Operanden mit 32 Bit ist eine Verschiebung um 32 undefiniert. In C17 ist die Linksverschiebung eines negativen vorzeichenbehafteten Werts undefiniert; auch 1 << 31 ist für einen int mit 32 Bit undefiniert, während 1u << 31 für einen unsigned int mit 32 Bit gültig ist.

Bei der Umwandlung einer Gleitkommazahl in eine Ganzzahl muss der abgeschnittene Wert darstellbar sein, auch wenn der Zieltyp vorzeichenlos ist. (unsigned)-1.0 ist undefiniert. Die Umwandlung einer Ganzzahl in einen vorzeichenlosen Typ reduziert den Wert dagegen auf dessen Wertebereich: (unsigned)-1 wird zu UINT_MAX. Die Umwandlung einer Ganzzahl außerhalb des Wertebereichs in einen vorzeichenbehafteten Typ ist in C17 implementierungsdefiniert. Prüfe Wertebereiche vor einer Typverengung; -Wconversion hilft, implizite Änderungen sichtbar zu machen.

Die Auswertungsreihenfolge unschädlich machen

printf("%d %d\n", i, ++i); liest und verändert i ohne die erforderliche Reihenfolge. Auch i = i++ + 1; und a[i] = i++; enthalten nicht sequenzierte Operationen. Teile die Arbeit in separate Anweisungen mit einer ausdrücklich festgelegten Reihenfolge auf.

Initialisiere automatische Variablen, bevor du sie liest: int sum = 0; macht sum += x; sinnvoll. Globale und statische Variablen beginnen bei null. Die in C23 vorgeschriebene Darstellung im Zweierkomplement definiert keinen Überlauf bei vorzeichenbehafteten Ganzzahlen; portabler Code benötigt weiterhin die Prüfungen.

Ein Zeiger braucht mehr als eine plausibel wirkende Adresse. Das Objekt muss existieren, der Zugriff muss innerhalb seiner Grenzen bleiben und die Operation muss für dieses Objekt erlaubt sein. Diese Prüfungen erklären sowohl unmittelbare Abstürze als auch Beschädigungen, die erst viel später entdeckt werden.

Innerhalb des Objekts bleiben

Ein Array mit n Elementen hat Indizes von null bis n - 1. Ein Zeiger unmittelbar hinter das letzte Element kann ein Schleifenende markieren, aber du darfst ihn nicht dereferenzieren. i <= n besucht ein Element zu viel. CERT ARR30-C behandelt diese Grenzfehler.

Ein Schreibzugriff außerhalb der Speichergrenzen kann in zugänglichem Speicher landen, der zu einem anderen Objekt gehört. Das Programm kann weiterlaufen, bis eine beschädigte Anzahl, ein beschädigter Zeiger oder ein beschädigter Eintrag der Speicherverwaltung verwendet wird. Ein späterer Absturz in free zeigt nicht den ursprünglichen Schreibzugriff. ASan kann beim Schreibzugriff anhalten, wenn seine Prüfungen die Grenzverletzung erkennen.

Zeichen zu einer gültigen Zeichenkette machen

Eine C-Zeichenkette endet mit '\0'. Ihr Speicher benötigt ein Byte mehr als ihre Anzahl an Zeichen. C akzeptiert char s[5] = "hello";, aber alle fünf Bytes enthalten Buchstaben, sodass kein Platz für ein abschließendes Nullzeichen bleibt. Wird das Array an strlen oder %s übergeben, kann über das Array hinaus gelesen werden. Verwende genügend Platz und stelle sicher, dass ein abschließendes Nullzeichen tatsächlich vorhanden ist. STR31-C behandelt die Kapazität; STR32-C behandelt die Übergabe einer abgeschlossenen Zeichenkette.

Ein Zeichenkettenliteral ist nicht beschreibbar. Nach char *p = "hi"; ist p[0] = 'H'; undefiniert. Verwende char p[] = "hi"; für eine beschreibbare Kopie oder const char *p, um Änderungsversuche am Literal für den Compiler sichtbar zu machen. Dies ist STR30-C.

Lebensdauer und Besitz beachten

Prüfe das Ergebnis einer Speicherallokation, einer Dateiöffnung oder einer Suche vor dem Dereferenzieren auf NULL. Wird ein Block freigegeben, verliert jeder Zeiger hinein den Zugriff auf ein noch existierendes Objekt. Lies und beschreibe den Block nicht und gib ihn nicht erneut frei. Gib nur den passenden Zeiger frei, der von einer dynamischen Speicherallokation zurückgegeben wurde, niemals ein lokales Array oder einen Zeiger ins Objektinnere. free(NULL) ist harmlos, aber wenn du einen Zeiger nach der Freigabe auf null setzt, werden andere Aliase dadurch nicht korrigiert.

Eine Funktion, die die Adresse eines lokalen Arrays zurückgibt, gibt einen hängenden Zeiger zurück:

char *greeting(void) {
    char text[16] = "Welcome";
    return text;
}

Die Lebensdauer des Arrays endet bei der Rückkehr aus der Funktion. Übergib der Funktion einen Puffer und seine Kapazität, den sie füllen kann, oder reserviere ein Ergebnis, dessen Besitz an den Aufrufer übergeht. Eine erfolgreiche Ausgabe unmittelbar nach der Rückkehr kann die Lebensdauer des alten Arrays nicht verlängern.

Byte für jedes Element reservieren

malloc(n) fordert Byte an, nicht n Objekte des Typs, auf den gezeigt wird. Der übliche elementbezogene Ausdruck ist n * sizeof *a. Verhindere zuerst, dass dieses Produkt durch Wraparound überläuft:

if (n > SIZE_MAX / sizeof *a) {
    /* reject the requested size */
}

Binde <stdint.h> für SIZE_MAX und <stdlib.h> für Allokationsfunktionen ein. Sobald die Größe gültig ist, reserviere den Speicher, prüfe den zurückgegebenen Zeiger und schreibe jeden Wert, bevor du ihn liest. malloc lässt den Speicher nicht initialisiert. calloc(n, sizeof *a) füllt seinen Speicher mit Nullen, und gängige Bibliotheken weisen überlaufende Produkte zurück. Eine Größenprüfung, eine Prüfung des Allokationsergebnisses und ein gültiger Index lösen unterschiedliche Probleme; alle drei sind wichtig.

Eine Zusicherung (Assertion) drückt etwas aus, das wahr sein sollte, weil dein eigener Code korrekt ist. Sie macht eine verborgene verletzte Annahme durch einen Halt nahe der Stelle sichtbar, an der diese Annahme wichtig ist.

Einen Programmiervertrag prüfen

Binde <assert.h> ein und schreibe assert(condition);. Eine wahre Bedingung lässt die Ausführung weiterlaufen. Eine falsche Bedingung gibt Diagnoseinformationen auf stderr aus und ruft abort() auf. Die Meldung nennt den Ausdruck, die Quelltextstelle und die Funktion; ihr genauer Wortlaut hängt von der Plattform ab.

Für eine interne Hilfsfunktion zur Mittelwertberechnung, deren Aufrufer gültige Argumente zusichert:

double average(const int *a, size_t n) {
    assert(a != NULL);
    assert(n > 0);
    /* compute the average */
}

Ein versehentlicher Aufruf mit null Elementen schlägt an der verletzten Zusage fehl. Unter einem Debugger zeigt bt die Zusicherung und den Abbruchmechanismus, gefolgt von den Aufrufen in deinem Code. Wähle den Stackframe des Aufrufers, um zu untersuchen, wie er null übergeben hat.

Verträge treten an mehreren Stellen auf:

Eine Zusicherung ist ausführbare Dokumentation: Sie benennt die Eigenschaft und prüft sie während eines Testlaufs. Wähle Ausdrücke, die den Zustand beobachten, ohne ihn zu verändern.

Benötigte Arbeit außerhalb von Zusicherungen halten

Wird NDEBUG vor dem Einbinden von <assert.h> definiert, üblicherweise mit -DNDEBUG, deaktiviert dies assert. Sein Ausdruck wird nicht ausgewertet. Das erzeugt einen schwerwiegenden Programmfehler, wenn der Ausdruck benötigte Arbeit ausführt:

assert(++count <= MAX);

In einem Build mit NDEBUG entfällt das Inkrement. Schreibe die Aktion gesondert:

++count;
assert(count <= MAX);

Dieselbe Regel schließt das Öffnen von Dateien, das Reservieren von Speicher und das Schließen von Dateien innerhalb einer Zusicherung aus. Diese Operationen müssen in allen Konfigurationen stattfinden. Ihre Fehler benötigen eine gewöhnliche Fehlerbehandlung.

Erwartete Fehler regulär behandeln

Eine fehlende Eingabedatei, ungültiger Benutzertext und ausgeschöpfter Speicher können bei korrekter Verwendung des Programms auftreten. Prüfe sie mit if, melde den Fehler und kehre zurück oder gib Ressourcen frei. Eine private Hilfsfunktion kann einen geprüften Wertebereich zusichern, aber an der öffentlichen Eingabeschnittstelle muss dieser Bereich mit Prüfungen durchgesetzt werden, die im Release-Build erhalten bleiben.

Prüfe zum Beispiel beim Schließen einer Ausgabedatei immer fclose(f) == EOF im gewöhnlichen Kontrollfluss. Gepufferte Ausgaben können beim Schließen fehlschlagen; wird der Aufruf oder seine Prüfung entfernt, kann das verlorene Daten verbergen.

Feste Sachverhalte zur Übersetzungszeit prüfen

Eine statische Zusicherung prüft beim Kompilieren einen konstanten Ausdruck. In C17 stellt <assert.h> static_assert als Makro für _Static_assert aus C11 bereit:

static_assert(sizeof(int) == 4, "requires a 4-byte int");

Eine falsche Bedingung lässt die Erstellung fehlschlagen. Eine vom Nutzer eingegebene Anzahl, die erst zur Laufzeit bekannt ist, kann sie nicht prüfen. C23 macht static_assert zu einem Schlüsselwort und erlaubt es, die Meldung wegzulassen. Nutze diesen Unterschied, um jede Prüfung dort zu platzieren, wo die benötigten Informationen verfügbar sind.

AddressSanitizer, gewöhnlich ASan genannt, ergänzt Prüfungen bei kompilierten Speicheroperationen. Er kann einen fehlerhaften Zugriff in dem Moment melden, in dem er geschieht, bevor beschädigte Daten einen späteren Absturz an anderer Stelle verursachen.

Mit eingebundenen Prüfungen erstellen

Verwende GCC oder Clang, um mit ASan zu kompilieren und zu linken:

clang -std=c17 -g -fsanitize=address -fno-omit-frame-pointer program.c -o program-asan

-g liefert Quelltextstellen. Das Beibehalten von Frame-Pointern hilft bei Aufrufrückverfolgungen. Instrumentiere bei einem Projekt mit mehreren Dateien die relevanten Quelldateien und verwende die Sanitizeroption auch beim abschließenden Linken. MSVC bietet /fsanitize=address für unterstützte Windows-Builds.

ASan erkennt viele Überläufe von Heap-Blöcken, Stack-Arrays und globalen Arrays. Außerdem erkennt er Zugriffe nach der Speicherfreigabe, doppelte und ungültige Speicherfreigaben sowie unterstützte Fälle der Verwendung nach Ende des Gültigkeitsbereichs. Unter Linux enthält die übliche ASan-Laufzeitumgebung eine Leckprüfung beim Programmende. Das mit macOS gelieferte Clang von Apple bietet diese Leckerkennung nicht; LLVM-Werkzeugketten und Plattformunterstützung unterscheiden sich.

Einem Bericht zur Ursache folgen

Betrachte ein erfolgreich reserviertes Array mit einem int von 4 Byte:

int *a = malloc(10 * sizeof *a);
for (int i = 0; i <= 10; ++i) {
    a[i] = i;
}

Der reservierte Block enthält 40 Byte. Die Indizes null bis neun nutzen diese Bytes. Index zehn beginnt unmittelbar dahinter. ASan kann „heap-buffer-overflow“, „WRITE of size 4“ und eine Stelle null Byte hinter einem Bereich von 40 Byte melden. Die Rückverfolgung des Schreibzugriffs bezeichnet die Zuweisung; die Rückverfolgung der Speicherallokation bezeichnet das malloc, das die Blockgrenzen festgelegt hat.

Lies Berichte in dieser Reihenfolge:

1. Bestimme die Fehlerkategorie und ob der Zugriff ein Lese- oder Schreibzugriff war.
2. Suche in der Rückverfolgung des Zugriffs den ersten Stackframe in deinem eigenen Code.
3. Vergleiche den Zugriff mit dem reservierten Bereich und seiner Elementgröße.
4. Suche bei einem Lebensdauerfehler auch die Rückverfolgungen der Allokation und der Freigabe.

Hier lautet die Korrektur i < 10. Ein weiteres Element zu reservieren und die falsche Abbruchregel beizubehalten, verbirgt die Abweichung zwischen der beabsichtigten Anzahl und der Schleife. ASan hält standardmäßig beim ersten erkannten Fehler an. Behebe ihn, erstelle das Programm erneut und führe es wieder aus.

Die Grenzen des Prüfwerkzeugs verstehen

ASan verfolgt zulässigen Speicher mithilfe von Schattenspeicher. Verbotene Redzones umgeben unterstützte Speicherblöcke und Arrays. Freigegebene Blöcke verbringen vor ihrer Wiederverwendung Zeit in einer Quarantäne, was veraltete Zugriffe sichtbar machen hilft. Ein Schreibzugriff über eine Arraykomponente hinaus in eine andere Komponente derselben Struktur kann innerhalb eines größeren gültigen Bereichs bleiben und unerkannt bleiben.

ASan prüft keine gewöhnlichen Lesezugriffe auf nicht initialisierte Werte. Memcheck von Valgrind kann diese Verwendungen und viele Heap-Defekte ohne erneute Kompilierung finden, läuft aber üblicherweise etwa 20- bis 30-mal langsamer. Die typische Verlangsamung durch ASan beträgt etwa das Zweifache, bei zusätzlichem Speicherverbrauch. Kombiniere einen ASan-Build nicht mit Valgrind, MemorySanitizer oder ThreadSanitizer. Führe gezielt Grenzfalleingaben aus: Ein Fehler auf einem nicht ausgeführten Pfad kann nicht im Bericht erscheinen.

Ein Speicherprüfwerkzeug deckt nicht jede ungültige C-Operation ab. UndefinedBehaviorSanitizer, kurz UBSan, instrumentiert viele arithmetische Operationen sowie Zeiger- und Arrayoperationen. Kombiniere ihn mit ASan, damit ein Testlauf mehr als eine Klasse von Defekten erkennen kann.

Arithmetische Fehler sichtbar machen

Bei einem int mit 32 Bit ergibt die Addition zweier Werte von 2.000.000.000 eine Summe von 4.000.000.000. Dieses Ergebnis überschreitet INT_MAX. Ein UBSan-Bericht erkennt den Überlauf bei vorzeichenbehafteten Ganzzahlen an der Addition und nennt die Operanden. Die Ausgabe eines negativ aussehenden Ergebnisses durch Wraparound ohne das Prüfwerkzeug würde die Operation nicht gültig machen.

Verwende für die Summe einen Typ, der den akzeptierten Bereich darstellen kann, oder lehne eine Addition ab, bevor sie überläuft. Das bereits übergelaufene Ergebnis in long long umzuwandeln, ist zu spät; die Operation selbst muss einen geeigneten Typ verwenden.

Ein üblicher Testbefehl lautet:

clang -std=c17 -Wall -Wextra -g -fsanitize=address,undefined -fno-omit-frame-pointer -fno-sanitize-recover=undefined program.c -o program-check

UBSan erlaubt normalerweise nach vielen Meldungen die Fortsetzung, sodass späterer Code weiterlaufen kann. -fno-sanitize-recover=undefined sorgt dafür, dass diese Fehler den Test mit einem Fehlerstatus beenden. Das hilft automatisierten Prüfungen, einen Programmfehler selbst dann zu erkennen, wenn die endgültige Ausgabe richtig aussieht.

Das Werkzeug auf den Defekt abstimmen

Wraparound bei vorzeichenlosen Ganzzahlen ist definiert, daher meldet die Gruppe undefined ihn nicht. Clang hat eine separate Prüfung mit -fsanitize=unsigned-integer-overflow für Code, bei dem Wraparound einen Programmfehler anzeigt. Schließe nicht daraus, dass jedes unerwünschte Ganzzahlergebnis UB ist.

MemorySanitizer ist ein Clang-Werkzeug, das hauptsächlich unter Linux eingesetzt wird; nicht instrumentierte Bibliotheken können seine Nachverfolgung stören. ThreadSanitizer erkennt widersprüchliche Zugriffe von Threads ohne Synchronisierung, von denen mindestens einer schreibt. Die Zugriffe müssen nicht genau zur selben Zeit stattfinden. Keines der beiden Werkzeuge lässt sich in einem Build mit ASan kombinieren.

Das Prüfen zur Routine machen

Lass Warnungen aktiviert und behebe sie. Erstelle das Programm mit ASan und UBSan und führe dann Tests mit leeren Eingaben, Eingaben mit einem Element, vollen Puffern, ungültigem Text und Werten nahe den zulässigen Schranken aus. Führe eine statische Analyse aus, um Pfade zu untersuchen, die die Tests möglicherweise übersehen, und wiederhole die Prüfungen automatisch, wenn sich der Code ändert. Führe auch die Release-Konfiguration aus, in der sich die Einstellungen für Optimierung und Zusicherungen unterscheiden.

Fuzzing liefert viele erzeugte oder veränderte Eingaben. libFuzzer und AFL++ können ungewöhnliche Parserpfade aufdecken; Sanitizer machen aus einer ausgelösten ungültigen Operation einen nützlichen Bericht. Speichere eine Eingabe, die einen Defekt findet, minimiere sie, ohne das Fehlverhalten zu verlieren, behebe die Ursache und behalte sie als Regressionstest. Ein fehlerfreier Lauf ist ein Beleg für die ausgeführten Eingaben, keine Garantie für alle möglichen Läufe.

Ein Standard für sichere Programmierung sammelt konkrete Regeln, die wiederkehrende Defekte verhindern. Er gibt einem Prüfer hilfreichere Fragen an die Hand als „Sieht das sicher aus?“. Jede Regel verbindet eine riskante Operation mit der Bedingung oder dem Entwurf, die oder der sie sicher macht.

Eine Regel verstehen

Der SEI CERT C Coding Standard stammt vom Software Engineering Institute der Carnegie Mellon University. Neben der Buchausgabe von 2016 gibt es eine sich weiterentwickelnde Onlineversion. Der Standard unterscheidet Regeln, deren Verletzung wahrscheinlich Defekte verursacht, von Empfehlungen, die Zuverlässigkeit und Sicherheit verbessern.

Kennungen verbinden eine Kategorie, eine Nummer und -C. Regeln verwenden die Nummern 30 bis 99; Empfehlungen verwenden 00 bis 29. Zum Beispiel betrifft INT32-C Überläufe bei vorzeichenbehafteten Ganzzahlen, während DCL00-C eine Empfehlung für Deklarationen ist. Zu den Kategorien gehören Deklarationen (DCL), Ausdrücke (EXP), Ganzzahlen (INT), Gleitkommazahlen (FLP), Arrays (ARR), Zeichenketten (STR), Speicher (MEM), Ein- und Ausgabe (FIO), Umgebung (ENV), Fehler (ERR) und Verschiedenes (MSC).

Eine Regelseite erklärt normalerweise den Defekt, zeigt nicht regelkonformen Code, stellt regelkonforme Lösungen vor und bewertet das Risiko. Lies die Annahmen jeder Lösung. Eine Ersatzfunktion ist nur nützlich, wenn ihr Verhalten die Anforderung tatsächlich erfüllt.

Eine Regel auf einen Datenpfad anwenden

FIO30-C betrifft Formatstrings. Dieser Code behandelt externe Daten wie ein Formatierungsprogramm:

printf(user_name);

Ein Benutzername mit Formatkonvertierungen veranlasst printf, nach nicht übergebenen Argumenten zu suchen; %n kann einen Schreibzugriff auf den Speicher verursachen. Halte das Format unter Kontrolle des Programms:

printf("%s", user_name);

Alternativ gibt fputs(user_name, stdout) den Text ohne Formatverarbeitung aus. -Wformat=2 enthält Prüfungen, die unsichere Formate finden helfen. Die Korrektur ändert, wie Daten interpretiert werden, nicht lediglich, wie lang die Zeichenkette sein darf.

Eine nützliche Prüfliste erstellen

Frage beim Speicher, ob Indizes innerhalb von Objekten bleiben (ARR30-C), der Speicher einer Zeichenkette das abschließende Nullzeichen enthält (STR31-C), auf freigegebenen Speicher nie zugegriffen wird (MEM30-C), Speicherblöcke in eigenem Besitz freigegeben werden (MEM31-C), nur gültige Speicherblöcke freigegeben werden (MEM34-C) und genügend Byte reserviert werden (MEM35-C).

Prüfe bei Ausdrücken unbeabsichtigten Wraparound bei vorzeichenlosen Ganzzahlen (INT30-C), Überlauf bei vorzeichenbehafteten Ganzzahlen (INT32-C), ungültige Division (INT33-C), Lesezugriffe auf nicht initialisierte Werte (EXP33-C) und das Dereferenzieren von Nullzeigern (EXP34-C). Behandle an Bibliotheksschnittstellen gemeldete Fehler (ERR33-C) und Konvertierungsfehler (ERR34-C). Vermeide system() gemäß ENV33-C, weil eine Shell dessen Eingabe interpretiert.

Risikotabellen bewerten Schweregrad, Wahrscheinlichkeit und Aufwand für die Behebung von 1 bis 3; eine höhere Bewertung des Aufwands bedeutet eine günstigere Behebung. Ihr Produkt ist die Priorität von 1 bis 27. Die Stufen gruppieren Prioritäten in L1 (12 bis 27), L2 (6 bis 9) und L3 (1 bis 4). Das hilft, Korrekturen zu ordnen, ohne Defekte mit niedrigerer Priorität für harmlos zu erklären.

Verwende Regeln bei der Codeüberprüfung und nutze Ergebnisse von Analysewerkzeugen, die ihren Kennungen zugeordnet sind. MISRA C ist ein weiterer Standard, der bei sicherheitskritischer eingebetteter Software verwendet wird. Regeln helfen, Defekte zu verhindern, während Warnungen, Tests und Sanitizer prüfen, ob die Implementierung sie tatsächlich befolgt. Das bloße Auswendiglernen von Kennungen kann weder ein fehlendes abschließendes Nullzeichen noch einen übersprungenen Fehlerzweig erkennen.

Sicherer Umgang mit Zeichenketten benötigt eine gültige Quelle, eine bekannte Zielkapazität und eine Entscheidung über Text, der nicht hineinpasst. Eine Funktion mit Größenbegrenzung verhindert manche Überschreibungen, aber du musst weiterhin prüfen, ob die gesamte Operation erfolgreich war.

Die Kapazität mit dem Zeiger übergeben

sizeof misst den Typ seines Operanden. Für ein lokales char buf[20] ergibt es 20 Byte. In void fill(char buf[]) wird der Parameter zu einem Zeiger angepasst; sizeof buf misst diesen Zeiger, nicht das Array des Aufrufers. Übergib einen Kapazitätsparameter, etwa mit fill(buf, sizeof buf), solange beim Aufrufer noch der Arraytyp vorliegt.

Eine Zeichenkette mit fünf Zeichen benötigt einschließlich '\0' sechs Byte. Die Kapazität zählt jedes beschreibbare Byte; die Zeichenkettenlänge schließt das abschließende Nullzeichen aus. Deshalb reserviert malloc(strlen(src)) für eine Kopie ein Byte zu wenig.

Eine begrenzte Zeile lesen

Verwende fgets(buf, sizeof buf, stdin) und prüfe den Rückgabewert, bevor du den Inhalt verwendest. Die Funktion speichert höchstens die Kapazität minus eins Zeichen und dann ein abschließendes Nullzeichen. Sie behält ein Zeilenumbruchzeichen, wenn dieses hineinpasst. Nach einem erfolgreichen Lesevorgang entfernt buf[strcspn(buf, "\n")] = '\0'; ein gespeichertes Zeilenumbruchzeichen.

Füllt eine lange Zeile den Puffer, bleiben ungelesene Zeichen für den nächsten Aufruf übrig. Entscheide, ob du den Rest ablehnst und aus der Eingabe entfernst, mehr liest oder das Abschneiden akzeptierst. Das Entfernen eines Zeilenumbruchzeichens beweist nicht, dass du die vollständige Zeile gelesen hast. Bei gets lässt sich keine Kapazität angeben; die Funktion wurde in C11 entfernt. Verwende sie niemals.

Für ein einzelnes Wort in char name[20] begrenzt %19s in scanf die gespeicherten Zeichen und lässt Platz für das abschließende Nullzeichen. Prüfe, ob die erwartete Anzahl an Konvertierungen erfolgreich war. Lies nicht vertrauenswürdigen numerischen Text vorzugsweise als vollständige Zeile und wandle ihn anschließend mit geprüftem strtol um; %d zeigt undefiniertes Verhalten, wenn der konvertierte Wert nicht darstellbar ist, selbst wenn du die Rückgabeanzahl von scanf prüfst.

Eine verkürzte Kopie erkennen

strcpy und strcat kennen die Kapazität des Ziels nicht. strncpy kann das Ergebnis ohne abschließendes Nullzeichen lassen. Bei positiver Kapazität schließt snprintf den gespeicherten Text mit einem Nullzeichen ab und meldet, wie viele Zeichen die vollständige Ausgabe benötigt hätte:

char dst[8];
int r = snprintf(dst, sizeof dst, "%s", "debugging");
if (r < 0) {
    /* report encoding failure */
} else if ((size_t)r >= sizeof dst) {
    /* report truncation */
}

Die gespeicherte Zeichenkette ist „debuggi“ und r ist 9. Die vollständige Ausgabe benötigt einschließlich ihres abschließenden Nullzeichens zehn Byte. Prüfe, ob das Ergebnis negativ ist, bevor du es in size_t umwandelst. Damit das Ergebnis hineinpasst, muss r kleiner als die Kapazität sein.

Die Operation auf den Speicher abstimmen

Verwende memmove, wenn sich Quelle und Ziel überlappen; memcpy bei Überlappung ist undefiniert. strlcpy ist auf BSD-Systemen, macOS und ab glibc 2.38 verfügbar, gehört aber nicht zu ISO C. Funktionen aus Anhang K sind optional und in vielen Bibliotheken nicht verfügbar.

Halte Benutzerdaten aus dem Format selbst heraus. Stimme jede Konvertierung auf ihr Argument ab: %d für int, %ld für long, %zu für size_t, %f für double und %s für eine abgeschlossene Zeichenkette. %p benötigt einen void *, übergib also einen passend umgewandelten Zeiger. Eine Breitenbegrenzung kann einen unpassenden Argumenttyp nicht korrigieren.

Externe Daten können syntaktisch gültig und dennoch für die beabsichtigte Operation unsicher sein. Prüfe ihre Länge, ihr vollständiges Format und ihren sinnvoll nutzbaren Wertebereich, bevor sie zu einem Index, einer Allokationsgröße oder einer Anzahl von Schleifendurchläufen werden.

Die vollständige Zahl einlesen

atoi bietet keine zuverlässige Möglichkeit, eine gültige null von ungültigem Text zu unterscheiden, und bei einem nicht darstellbaren Ergebnis ist das Verhalten undefiniert. strtol liefert einen Endzeiger und meldet einen Wertebereichsfehler. Nachdem eine vollständige Zeile gelesen und ihr Zeilenumbruchzeichen entfernt wurde, kann ein strenger Parser für Dezimalzahlen Folgendes verwenden:

errno = 0;
char *end;
long v = strtol(text, &end, 10);
if (end == text || *end != '\0' || errno == ERANGE) {
    /* reject the numeric text */
} else if (v < 0 || v > 150) {
    /* reject this application's range */
} else {
    int age = (int)v;
    /* use age */
}

Binde <errno.h> und <stdlib.h> ein. Der erste Test unterscheidet drei Fehler: keine Ziffern, nachfolgenden Text und einen Wert außerhalb des Wertebereichs von long. Die Prüfung des anwendungsspezifischen Wertebereichs erfolgt vor der Verengung auf int. strtol akzeptiert führende Leerzeichen und ein optionales Vorzeichen; entscheide, ob die Grammatik der Anwendung sie erlaubt.

Für „42abc“ kann die Konvertierung 42 zurückgeben, aber end zeigt auf die verbleibenden Buchstaben. Für „abc“ werden keine Ziffern eingelesen. Bei einer zu großen dezimalen Ganzzahl wird errno zu ERANGE. Eine zurückgegebene Zahl ungleich null allein belegt weder eine vollständige Konvertierung noch einen sicheren Wertebereich.

Den Besitz im Fehlerfall erhalten

Jede Operation, die fehlschlagen kann, benötigt eine Reaktion. Prüfe Allokationsergebnisse, fopen, fgets, die Anzahl der Konvertierungen und den Abschluss von Ausgaben. Gibt fgets den Wert NULL zurück, kann das Eingabeende oder einen Lesefehler bedeuten. fclose kann einen Fehler beim gepufferten Schreiben melden. Verwende die zur Funktion passenden Fehlerinformationen; viele Bibliotheksaufrufe setzen errno, das perror oder strerror in eine lesbare Fehlermeldung umwandeln kann.

Schütze bei einer Größenänderung auf einen positiven Wert die Größenberechnung und den ursprünglichen Speicherblock:

if (new_n == 0) {
    free(a);
    a = NULL;
} else if (new_n > SIZE_MAX / sizeof *a) {
    /* reject the size */
} else {
    int *tmp = realloc(a, new_n * sizeof *a);
    if (tmp == NULL) {
        /* handle failure; a still owns its old block */
    } else {
        a = tmp;
    }
}

Wird das Ergebnis von realloc direkt dem einzigen besitzenden Zeiger zugewiesen, geht bei einem Fehler die Adresse des alten Blocks verloren. Behandle null gesondert: C17 macht realloc mit Größe null implementierungsdefiniert, C23 dagegen undefiniert. Verwende nach erfolgreicher Größenänderung den zurückgegebenen Zeiger und verwirf veraltete Aliase.

Einen klaren Fehlerpfad vorsehen

Ein einzelner Aufräumabschnitt kann angeforderte Ressourcen in umgekehrter Reihenfolge freigeben. Initialisiere besitzende Zeiger mit NULL, schließe nur geöffnete Dateien und gib nach der Meldung der Ursache einen Fehlerstatus zurück. Ein goto cleanup kann diese Pfade leichter überprüfbar machen.

Vermeide system() für Aufgaben mit externem Text: Die Shell kann diesen Text als Befehle interpretieren. Verwende vorzugsweise eine Bibliotheksoperation oder eine geeignete Schnittstelle zum Starten von Programmen, an die Argumente getrennt übergeben werden. Behandle Kommandozeilenargumente, Umgebungswerte, Dateiinhalte und Netzwerkdaten als Eingaben, die dieselbe Sorgfalt benötigen wie eingetippter Text.

Speichersicherheit bedeutet, dass Zugriffe innerhalb des Speichers bleiben, den ein Programm verwenden darf. C bietet direkte Kontrolle über den Speicher und überlässt Grenzen- und Lebensdauerprüfungen dem Programmierer.

Grenzen und Lebensdauer unterscheiden

Räumliche Sicherheit hält einen Zugriff innerhalb der Grenzen seines Objekts. Das Schreiben von Element zehn eines Arrays mit zehn Elementen verletzt sie. Zeitliche Sicherheit hält Zugriffe innerhalb der Lebensdauer des Objekts. Eine Speicherallokation nach free zu lesen, sie zweimal freizugeben oder eine zurückgegebene lokale Adresse zu verwenden, verletzt Lebensdauerregeln.

Die Folgen können über einen Absturz hinausgehen. Ein Lesezugriff kann vertrauliche Daten preisgeben. Ein Schreibzugriff kann eine Datei beschädigen, Kontrolldaten verändern oder eine Sicherheitslücke schaffen, wenn externe Eingaben die Operation steuern. Ein Programm, das nach einer Beschädigung weiterläuft, kann überzeugende, aber falsche Ergebnisse liefern.

Diese Belastung betrifft auch erfahrene Teams. Microsoft berichtete 2019, dass über mehr als ein Jahrzehnt hinweg Jahr für Jahr etwa 70 % der Sicherheitslücken, denen das Unternehmen CVE-Kennungen zugewiesen hatte, die Speichersicherheit betrafen. Im Dezember 2023 forderten CISA und Partnerbehörden Softwarehersteller auf, Übergänge zu speichersicheren Programmiersprachen zu planen. Dies sind konkrete historische Beobachtungen, kein gemessener Prozentsatz für jedes C-Programm.

Gründe für die Wahl von C verstehen

C bietet Kontrolle über Speicherlayout, Speicherallokation und Hardwarezugriff, ohne automatische Speicherbereinigung zu benötigen. Seine kleine Laufzeitumgebung eignet sich für Firmware mit begrenzten Ressourcen. Es gibt breite Compilerunterstützung, große vorhandene Codebestände und Schnittstellen, die viele andere Sprachen aufrufen können. Diese Vorteile erklären seinen Einsatz in Betriebssystemkernen, eingebetteter Software, Laufzeitumgebungen und Bibliotheken.

Sie machen nicht jedes C-Programm vorhersagbar schnell: Algorithmen, Speicherallokation, Caches und Systemaufrufe sind weiterhin wichtig. Der entscheidende Vorteil ist die Kontrolle über Kosten und Laufzeitanforderungen.

Unsichere Operationen und Schnittstellen zu C benötigen in ansonsten speichersicheren Systemen besondere Sorgfalt. Speichersicherheit lässt außerdem logische Fehler und durch Eingaben ausgelöste Injection als zu lösende Probleme bestehen.

Schutzebenen für das verbleibende Risiko wählen

Verhindere Defekte mit Programmierregeln, Warnungen und Codeüberprüfung. Erkenne Defekte mit statischer Analyse, Grenzfalltests, Sanitizern und Fuzzing. Begrenze verbleibende Schäden mit Stack-Schutz, unterstützten _FORTIFY_SOURCE-Prüfungen, zufälliger Anordnung des Adressraums (ASLR) und nicht ausführbarem Speicher. Eine Schutzmaßnahme kann einen Angriff stoppen oder eine Beschädigung in einen Absturz umwandeln, während der Defekt im Quelltext bestehen bleibt.

Die Kosten bestimmen den Einsatz. ASan verdoppelt typischerweise die Ausführungszeit und erhöht den Speicherbedarf; Valgrind verlangsamt die Ausführung üblicherweise um das 20- bis 30-Fache. Sie eignen sich besser für Tests als für den gewöhnlichen Einsatz in veröffentlichten Programmen. Härtungsmaßnahmen mit geringeren Kosten bleiben häufig in Release-Builds erhalten.

Für einen neuen Parser für Dateien aus dem Internet, bei dem keine Einschränkung C verlangt, verringert eine speichersichere Sprache ein großes Risiko. Bei vorhandener C-Firmware auf einem Mikrocontroller mit 32 KB Speicher können Sprachunterstützung und Ressourcenbeschränkungen für C mit strengen Prüfungen sprechen. Triff die Wahl anhand von Einschränkungen, Kontakt mit Eingaben und Wartbarkeit; auch der schrittweise Ersatz eines riskanten Parsers kann praktikabel sein.