Debuggen, ongedefinieerd gedrag en veilig C programmeren

Waarschuwingen geven je de kans een fout te herstellen voordat invoer die veroorzaakt. Een fout verhindert dat het bouwproces slaagt. Een waarschuwing laat het bouwproces doorgaan, maar meldt iets wat je moet begrijpen: verdachte geldige code, mogelijk ongedefinieerd gedrag of een overtreding van een taalregel die de compiler accepteert.

Kies nuttige controles

Start GCC of Clang met een expliciete taalversie en een brede set waarschuwingen:

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

-Wall schakelt veel algemene controles in, niet alle waarschuwingen. -Wextra voegt er meer toe, waaronder vergelijkingen van waarden met en zonder teken in C. -Wpedantic meldt veel afwijkingen van de gekozen ISO-standaard; het is geen volledige controle op naleving van de standaard. /W4 van MSVC dient een vergelijkbaar doel op Windows.

Voeg controles toe die passen bij de risico’s in je code:

Bijvoorbeeld: double price = 3.7; int whole = price; laat het gebroken deel weg. -Wconversion maakt die conversie zichtbaar. Als afkapping de bedoeling is en de waarde past, legt (int)price die keuze vast. Als het gebroken deel van belang is, behoud dan een drijvendekommatype. Voor afronden op het dichtstbijzijnde gehele getal heeft lround uit <math.h> een andere taak dan een expliciete typeconversie.

Lees de eerste bruikbare melding

Een diagnostische melding vermeldt normaal gesproken een locatie in de broncode, een melding en de waarschuwingsoptie. Een dakje markeert de relevante expressie; daaropvolgende opmerkingen kunnen een declaratie aanwijzen of een oplossing voorstellen. Lees de hele groep. Als één syntaxisfout veel latere meldingen veroorzaakt, herstel dan de eerste fout en compileer opnieuw voordat je de rest onderzoekt.

Stel dat een programma deze drie regels bevat, waarbij average is gedeclareerd als double:

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

De toewijzing in de voorwaarde stelt count in op nul, waardoor de voorwaarde onwaar wordt. Als een vergelijking de bedoeling was, gebruik dan count == 0. Haakjes rond de toewijzing toevoegen kan een waarschuwing onderdrukken terwijl de programmeerfout blijft bestaan.

Het formaat %d verwacht een int, maar het argument is een double. Gebruik %f; een niet-passend formaat is ongedefinieerd gedrag, geen verzoek om de waarde te converteren. Verwijder de ongebruikte declaratie als die geen doel dient. Dit zijn drie verschillende oorzaken, dus elke oorzaak heeft een eigen oplossing nodig.

Volg de aanwijzingen

Let goed op niet-geïnitialiseerde waarden, ontbrekende retourinstructies, adressen van lokale variabelen die worden teruggegeven en sizeof op arrayparameters. Door een ontbrekend headerbestand kan een functie ongedeclareerd blijven; recente versies van GCC en Clang wijzen dit standaard af. Voeg niet zomaar een expliciete typeconversie toe om een diagnostische melding te laten verdwijnen. Leg eerst uit welke typen en waarden de bedoeling zijn en zorg daarna dat de code die bedoeling uitdrukt.

Een programma zonder waarschuwingen kan nog steeds een onjuiste lusvoorwaarde of een verkeerde index uit de invoer hebben. Sommige waarschuwingen hangen ook af van optimalisatie en gegevensstroomanalyse, en verschillende compilers vinden verschillende gevallen. Houd de waarschuwingsset ingeschakeld in gewone bouwprocessen en onderzoek daarna het gedrag tijdens de uitvoering met de debugger en testhulpmiddelen.

Dezelfde broncode kan worden gebouwd voor gemakkelijke inspectie, intensief testen of efficiënte productie. Bouwinstellingen bepalen welke informatie je kunt zien en welke extra controles worden uitgevoerd. Geef elke versie een duidelijk doel.

Bewaar broncode-informatie

De optie -g voegt namen, typen en koppelingen tussen machine-instructies en broncoderegels toe. Hiermee kan een debugger je code tonen en kunnen sanitizerrapporten locaties aanwijzen. De optie schakelt geen controles tijdens de uitvoering in en schakelt optimalisatie niet uit. Zonder debuginformatie blijven sommige functienamen mogelijk beschikbaar, maar broncoderegels en lokale variabelen zijn veel moeilijker te achterhalen.

Optimalisatie verandert hoe nauw de uitvoering de volgorde van de broncode volgt:

Tijdens een debugsessie met geoptimaliseerde code kunnen regels worden overgeslagen of kan een variabele als “” worden getoond. De compiler heeft het gedrag van gedefinieerde code behouden, maar bewaart mogelijk niet meer elke tussenwaarde uit de broncode. -O0 vertaalt niet letterlijk elke C-regel naar één machine-instructie.

Bouw voor het doel

Een eenvoudige debugopdracht is:

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

Een testversie voegt sanitizers toe. Een productieversie gebruikt gewoonlijk -O2 en kan NDEBUG definiëren om asserties te verwijderen. Gewone invoervalidatie en foutafhandeling moeten actief blijven wanneer asserties verdwijnen. Test ook de productieconfiguratie: een probleem dat alleen bij optimalisatie zichtbaar is, is een sterke reden om ongedefinieerd gedrag te onderzoeken, waaronder het lezen van niet-geïnitialiseerde waarden en overloop bij gehele getallen met teken.

Bewaar gedeelde opties in een Makefile of een andere bouwconfiguratie. Afzonderlijke uitvoerbestandsnamen voorkomen dat je per ongeluk een oud uitvoerbaar productiebestand uitvoert terwijl je zojuist bewerkte broncode bekijkt. Bouw na elke wijziging in de broncode het uitvoerbare bestand dat je wilt uitvoeren opnieuw.

Voeg analyse en beveiligingsversterking toe

Statische analyse volgt mogelijke paden door de broncode zonder het programma uit te voeren. Probeer gcc -fanalyzer of clang --analyze; scan-build, clang-tidy en cppcheck bieden andere werkwijzen voor analyse. Een analysetool kan opmerken dat een fouttak een pointer tweemaal vrijgeeft, ook als je tests die tak nooit bereiken. Beoordeel de redenering: analyse van mogelijke paden kan valse meldingen opleveren.

Dynamische analyse controleert de daadwerkelijke uitvoering. Sanitizers en Valgrind zien alleen de paden die je uitvoert, dus hun dekking hangt af van je invoer. Combineer beide soorten analyse.

Beveiligingsversterking voor productie beperkt de schade door achtergebleven fouten. -fstack-protector-strong plaatst controles in geselecteerde stackframes om veel overschrijvingen te detecteren. Op systemen die dit ondersteunen, voegt _FORTIFY_SOURCE controles toe aan bibliotheekaanroepen wanneer de objectgroottes kunnen worden bepaald. Dit vereist optimalisatie; niveau 2 is gebruikelijk, terwijl niveau 3 geschikte ondersteuning van de compiler en C-bibliotheek vereist. Dit zijn platformfuncties, geen garanties van ISO C.

Een beveiligd programma kan stoppen wanneer het beschadiging detecteert. De ongeldige bewerking moet nog steeds in de broncode worden hersteld; andere productieopties kunnen een lus die buiten de grenzen gaat niet corrigeren.

Falen is het gedrag dat je ziet: een crash, een verkeerd totaal of uitvoer die nooit verschijnt. Een programmeerfout is de vergissing die dat gedrag veroorzaakte. Door die uit elkaar te houden, voorkom je dat je de crashregel verandert voordat je hebt ontdekt hoe het programma daar terechtkwam.

Maak het falen reproduceerbaar

Leg de opdracht, invoer, bouwopties, het verwachte resultaat en het werkelijke resultaat vast. Houd de invoer die het falen veroorzaakt ongewijzigd terwijl je experimenteert. Als een programma alleen bij één bestand faalt, sla dat bestand dan op voordat je het bewerkt. Door het falen te reproduceren kun je beoordelen of een voorgestelde oplossing werkt.

Maak het voorbeeld vervolgens kleiner terwijl het falen blijft optreden. Verwijder niet-gerelateerde records of code en voer het opnieuw uit. Stel dat één record uit 1.000 afzonderlijk een crash veroorzaakt. Door helften te proberen kun je dat record in ongeveer 10 rondes vinden. Als geen van beide helften afzonderlijk faalt, vereist het falen mogelijk een reeks records of een eerder opgebouwde toestand. Behoud die reeks en verwijder kleinere stukken eromheen. Halveren is alleen nuttig als de behouden invoer de oorzaak nog steeds aanspreekt.

Stel één toetsbare vraag

Een leeg veld in een geminimaliseerd bestand suggereert een hypothese: “De parser gebruikt het veld voordat wordt gecontroleerd of het bestaat.” Toets die met een kleine invoer met een leeg veld. Bekijk de teruggegeven pointer of voeg één gerichte controle toe. Verander één ding tegelijk; als je de parser, buffergrootte en invoer samen wijzigt, vertelt succes je niet welke wijziging van belang was.

Herstel de overtreden regel, voer het geminimaliseerde voorbeeld opnieuw uit en voer daarna de oorspronkelijke invoer en bestaande tests opnieuw uit. Bewaar de aanleiding als regressietest, zodat een latere wijziging niet ongemerkt hetzelfde falen kan terugbrengen.

Interpreteer het stoppen

“Segmentation fault” meldt meestal SIGSEGV: het systeem heeft een ongeldige geheugentoegang gestopt. Een nulpointer, een pointer naar vrijgegeven geheugen of een adres buiten het bereik is een veelvoorkomende oorzaak. Een ongeldige toegang kan ook optreden zonder directe crash, dus het uitblijven van een melding zegt op zichzelf weinig.

“Aborted” meldt vaak SIGABRT, veroorzaakt door abort(). Een mislukte assertie of een bibliotheekcontrole die beschadiging van de heap detecteert kan dit veroorzaken. In bash zijn gebruikelijke afsluitstatussen voor signalen 139 voor SIGSEGV en 134 voor SIGABRT; dit zijn shellconventies, geen C-retourwaarden die je programma moet gebruiken.

Observeer zonder uitvoer te verliezen

Een korte diagnostische melding kan de eerste verkeerde waarde zichtbaar maken:

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

Labels maken de uitvoer leesbaar wanneer dezelfde regel vaak wordt uitgevoerd. stderr is nuttig voor diagnostische meldingen omdat het niet volledig gebufferd is; stdout dat naar een bestand of pipe wordt omgeleid, is normaal gesproken volledig gebufferd, zodat bij een crash nog niet weggeschreven uitvoer verloren kan gaan. Verwijder tijdelijke uitvoerinstructies na het herstel.

Leg een verdachte functie regel voor regel hardop uit. Deze methode met een “badeend” dwingt je om elke bewerking te vergelijken met het gedrag dat je bedoelt. Als een programmeerfout verandert wanneer je uitvoerinstructies toevoegt of de optimalisatie wijzigt, onderzoek dan met sanitizers of er ongedefinieerd gedrag is. Een array groter maken totdat een crash verdwijnt, kan een ongeldige index verbergen zonder die te herstellen.

Met een debugger kun je een draaiend programma pauzeren en de waarden bekijken die het gedrag verklaren. Gebruik GDB op veel Linux-systemen of LLDB op macOS. Debugknoppen in IDE’s gebruiken dezelfde ideeën: stoppen, uitvoeren, bekijken en stapsgewijs uitvoeren.

Begin met het juiste uitvoerbare bestand

Compileer met -g -O0 en open het resultaat met gdb ./program of lldb ./program. Bij de prompt start run records.txt 3 het programma met twee argumenten. In GDB leidt run < input.txt de standaardinvoer om; gebruik in LLDB process launch -i input.txt. Gebruik quit om af te sluiten.

Stel vóór de uitvoering een breekpunt in. break main in GDB en b main in LLDB stoppen aan het begin van main. Beide accepteren een locatie met bestand en regel, zoals b program.c:12. Volledige LLDB-opdrachten zijn onder meer breakpoint set --name main en breakpoint set --file program.c --line 12.

Een breekpunt stopt normaal gesproken voordat de aangegeven broncode-instructie wordt uitgevoerd. Als de geselecteerde regel een waarde toewijst, druk die dan af nadat je de regel hebt uitgevoerd om de nieuwe waarde te bekijken. Bouw het programma opnieuw na wijzigingen in de broncode: de debugger voert machinecode uit, niet de tekst die in je editor openstaat.

Kies hoe je verdergaat

Andere breekpunten kunnen next of finish onderbreken. Gebruik next voor een bibliotheekaanroep die je niet hoeft te onderzoeken. Als je ongewenste code instapt, brengt finish de besturing terug naar de aanroepende functie.

Bekijk een lus per iteratie

Neem een totaal dat op nul is geïnitialiseerd en deze array:

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

Stop bij de lusinhoud en druk i en sum af vóór de optelling. Na de eerste vijf optellingen zijn de tussentotalen 4, 12, 27, 43 en 66. Bij de volgende pauze geldt i == 5, maar de geldige indices eindigen bij 4. Je hebt de extra iteratie gevonden zonder het ongeldige element te hoeven lezen. Verander de voorwaarde in i < 5, bouw opnieuw en voer opnieuw uit.

print expr of p expr evalueert een expressie in beide debuggers. Begin met veilige waarnemingen zoals p i en p sum; een debuggerexpressie die een ongeldige pointer derefereert, kan zelf een ongeldige leesbewerking proberen. display i van GDB herhaalt de uitvoer bij elke pauze. info locals in GDB en frame variable in LLDB tonen lokale variabelen. Gebruik voor vijf geldige elementen via ptr de opdracht p *ptr@5 van GDB of parray 5 ptr van LLDB.

Je kunt een hypothese toetsen door een waarde tijdens een pauze te veranderen: GDB accepteert set var i = 4, LLDB accepteert expr i = 4. Dit verandert één uitvoering, niet de broncode. Gebruik om breekpunten te beheren info breakpoints en delete 1 van GDB, of breakpoint list en breakpoint delete 1 van LLDB.

Een crash binnen een bibliotheek begint vaak met een ongeldig argument uit je eigen code. De aanroepstapel toont de actieve functieaanroepen. Gebruik die om van de stoplocatie naar de aanroepende functie te gaan waarvan je de waarden kunt verklaren.

Lees stackframes vanaf de huidige aanroep naar buiten

Typ bt in een van beide debuggers. Stackframe #0 is de binnenste actieve aanroep; hogere stackframenummers zijn de aanroepende functies daarvan. Een stackframe geeft de uitvoeringscontext van de functie, waaronder beschikbare argumenten en lokale variabelen. Optimalisatie kan een deel van die informatie verwijderen.

Stel dat find_name(2) geen overeenkomst teruggeeft en de aanroepende functie dit doet:

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

Het programma kan binnen strlen stoppen. Zoek in bt het eerste stackframe dat bij je code hoort. Selecteer het met frame 1 in GDB of frame select 1 in LLDB als het stackframe 1 is. Druk name af. Een nulwaarde verklaart waarom de stringbewerking mislukte. De aanroepende functie moet de ontbrekende naam afhandelen voordat die strlen aanroept; de bibliotheek bewerken kan het argument niet herstellen.

Gebruik up en down om tussen aanroepende en aangeroepen functies te bewegen. Als je een stackframe selecteert, verandert wat de debugger toont en naar welke lokale variabelen een expressie verwijst. De uitvoering wordt niet hervat en een aanroep wordt niet ongedaan gemaakt.

Stop waar een waarde verandert

Een breekpunt vraagt: “Wat gebeurt er op deze plek?” Een gegevensbreekpunt vraagt: “Welke bewerking verandert deze waarde?” Als een opgeslagen aantal lang vóór een crash verkeerd wordt, pauzeer dan terwijl het aantal binnen het geldigheidsgebied is en gebruik:

GDB:  watch count
LLDB: watchpoint set variable count

Ga door totdat de debugger stopt bij een wijziging. Bekijk de oude en nieuwe waarde en de broncodelocatie van de schrijfinstructie. Een wijziging kan terecht zijn, dus vergelijk die met de regel van de gegevensstructuur. Hardware biedt slechts een klein aantal gegevensbreekpunten; vier is gebruikelijk op x86-64. De opslag van een lokale variabele heeft alleen betekenis zolang de functie actief is.

Gebruik voor een bekende late iteratie een voorwaardelijk breekpunt. break 20 if i == 999 van GDB pauzeert alleen op regel 20 wanneer de voorwaarde geldt. Het equivalent in LLDB is breakpoint set --line 20 --condition 'i == 999'. Dit bespaart honderden handmatige stappen.

Bekijk een opgeslagen crash

Een geheugendump legt de toestand van een gecrasht proces vast. Waar geheugendumps zijn ingeschakeld, staat ulimit -c unlimited ze toe voor programma’s die vanuit die shell worden gestart. Open een opgeslagen dump met gdb ./program core of lldb ./program -c core, met het uitvoerbare bestand dat de dump heeft gemaakt. Systeeminstellingen bepalen of een dump wordt opgeslagen en waar die terechtkomt; Linux-systemen met systemd kunnen dit via coredumpctl beheren.

Voer bt uit, selecteer je stackframe en bekijk waarden zoals bij een actuele crash. Met de dump kun je het programma niet voortzetten. Als malloc of free beschadiging detecteert, kan de oorspronkelijke ongeldige schrijfbewerking ontbreken in deze aanroepstapel. Reproduceer het probleem met AddressSanitizer om dichter bij die schrijfbewerking te stoppen. Als een lokale waarde willekeurig lijkt, controleer dan of de uitvoering de initialisator heeft bereikt voordat je de debugger de schuld geeft.

Ongedefinieerd gedrag betekent dat de C-standaard geen eisen stelt aan wat er gebeurt na een ongeldige bewerking. De standaard belooft geen uitzondering, bruikbare foutmelding of voorspelbaar teruggelopen waarde. Een programma kan crashen, gegevens beschadigen, een aannemelijk antwoord afdrukken of lijken te werken.

Onderscheid drie soorten gedrag

Door de implementatie bepaald gedrag kun je bewust gebruiken wanneer het gedocumenteerde platform deel uitmaakt van het ontwerp van een programma. Ga er voor overdraagbare code niet van uit dat alle implementaties dezelfde keuze maken. Niet-gespecificeerd gedrag is ook geldig: f(a(), b()) kan elk van beide onafhankelijke aanroepen als eerste evalueren. Schrijf code waarvan de correctheid bij die toegestane variatie behouden blijft. De bitbreedte van int en, in C17, het naar rechts verschuiven van een negatief geheel getal met teken zijn andere platformafhankelijke keuzes.

Waarom optimalisatie programmeerfouten zichtbaar maakt

C laat controles van arraygrenzen en optellingen met teken aan de programmeur over. De compiler mag optimaliseren vanuit de aanname dat het programma de regels van de taal volgt. Een poging om overloop te detecteren kan juist de regel overtreden die de code probeert te toetsen:

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

Voor elke x waarvoor optelling met teken is gedefinieerd, is x + 1 groter dan x. De compiler kan het resultaat daarom door nul vervangen. Bij INT_MAX is het uitvoeren van de optelling ongedefinieerd gedrag, dus hoeft de compiler de aanroepende functie geen teruggelopen resultaat te geven. Een ander antwoord in een niet-geoptimaliseerde versie maakt dit geen geldige test.

De veilige test vindt vóór de bewerking plaats:

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

Gebruik <limits.h> voor de grenzen van de implementatie. Een vast geprogrammeerd maximum veronderstelt een bepaalde typebreedte; de macro geeft de werkelijke grens aan.

Plaats controles vóór het eerste gebruik

Deze volgorde is ook essentieel voor pointers:

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

Als je deze instructies omdraait, kan een nulpointer worden gederefereerd voordat de bescherming werkt. Zodra code p derefereert, kan een optimizer redeneren dat het gedefinieerde pad al vereist dat p geen nulpointer is en een latere controle op nul verwijderen.

Andere opties instellen, een uitvoerinstructie toevoegen of een variabele verplaatsen kan het zichtbare verschijnsel van ongedefinieerd gedrag veranderen. Een geslaagde uitvoering toont alleen aan wat die versie met die invoer deed. Om de code te herstellen, bepaal je welke bewerking geen gedefinieerde betekenis heeft en welke voorwaarde daarvoor moet gelden. Waarschuwingen kunnen sommige gevallen aanwijzen; statische analyse kan mogelijke paden onderzoeken; ASan en UBSan controleren veel uitgevoerde bewerkingen. Programmeerregels bieden de bijbehorende patronen op broncodeniveau, zoals een index of een rekenkundige grens controleren vóór gebruik.

Een berekening kan al misgaan voordat je de kans hebt het resultaat te bekijken. Controleer de operanden zolang hun waarden nog geldig zijn en weet welk type elke bewerking uitvoert.

Grenzen voor getallen met en zonder teken

Overloop bij gehele getallen met teken is ongedefinieerd. Bij een 32-bits int is INT_MAX 2.147.483.647; er één bij optellen is geen overdraagbare manier om een negatief getal te krijgen. Ook INT_MIN / -1, -INT_MIN en te grote vermenigvuldigingen gaan mis als het wiskundige resultaat niet past.

Rekenen met gehele getallen zonder teken loopt modulair terug binnen het bereik van het type. Bij een 32-bits unsigned int is UINT_MAX + 1u nul en 0u - 1u 4.294.967.295. Dit is gedefinieerd, maar kan een grootteberekening toch onjuist maken. Een achterwaartse lus met een waarde zonder teken die i >= 0 gebruikt, bereikt nooit een negatieve stopwaarde.

Controleer vóór het optellen voor een algemene optelling met teken:

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

De aftrekkingen in deze tests blijven binnen het bereik omdat elke aftrekking wordt beschermd door het teken van b. Eerst de som berekenen en die daarna vergelijken is te laat. Een breder type helpt alleen als elk tussenresultaat erin past: converteer een operand vóór de bewerking. C23 biedt ckd_add in <stdckdint.h>; GCC en Clang bieden __builtin_add_overflow.

Deling, bitverschuivingen en conversies

Wijs nul af vóór een geheeltallige deling of restberekening. Wijs ook het minimum van een type met teken gedeeld door min één af wanneer het resultaat niet past. Drijvendekommasystemen volgens IEEE 754 leveren bij deling door nul vaak oneindig of NaN op, waardoor ongeldige numerieke resultaten zich kunnen verspreiden zonder een onderbreking zoals bij gehele getallen.

Gebruik voor bitbewerkingen operanden zonder teken. Het aantal posities voor de verschuiving moet niet-negatief en kleiner zijn dan de bitbreedte van de gepromoveerde linkeroperand. Bij 32-bits operanden is verschuiven met 32 posities ongedefinieerd. In C17 is een negatieve waarde met teken naar links verschuiven ongedefinieerd; 1 << 31 is ook ongedefinieerd voor een 32-bits int, terwijl 1u << 31 geldig is voor een 32-bits unsigned int.

Bij een conversie van een drijvendekommawaarde naar een geheel getal moet de afgekaptе waarde passen, ook als het doeltype geen teken heeft. (unsigned)-1.0 is ongedefinieerd. Een conversie van een geheel getal naar een type zonder teken brengt de waarde daarentegen terug binnen het bereik van het doeltype: (unsigned)-1 wordt UINT_MAX. Een conversie van een geheel getal buiten het bereik naar een type met teken is in C17 door de implementatie bepaald. Controleer bereiken vóór een conversie naar een smaller type; -Wconversion helpt impliciete veranderingen zichtbaar te maken.

Maak de evaluatievolgorde onschadelijk

printf("%d %d\n", i, ++i); leest en verandert i zonder de vereiste ordening. i = i++ + 1; en a[i] = i++; bevatten ook niet-geordende bewerkingen. Splits de bewerkingen op in afzonderlijke instructies met een expliciete bedoelde volgorde.

Initialiseer automatische variabelen voordat je ze leest: int sum = 0; maakt sum += x; betekenisvol. Globale en statische variabelen beginnen op nul. De eis van C23 voor een tweecomplementvoorstelling definieert overloop bij gehele getallen met teken niet; overdraagbare code heeft nog steeds de controles nodig.

Een pointer heeft meer nodig dan een aannemelijk adres. Het object moet bestaan, de toegang moet binnen de grenzen ervan blijven en de bewerking moet voor dat object zijn toegestaan. Deze controles verklaren zowel directe crashes als beschadiging die veel later wordt ontdekt.

Blijf binnen het object

Een array van n elementen heeft indices van nul tot en met n - 1. Een pointer direct voorbij het laatste element kan het einde van een lus markeren, maar je mag die niet derefereren. i <= n bezoekt één element te veel. CERT ARR30-C behandelt deze grensfouten.

Een schrijfbewerking buiten de grenzen kan terechtkomen in toegankelijk geheugen dat bij een ander object hoort. Het programma kan doorgaan totdat een beschadigd aantal, een beschadigde pointer of een beschadigd record van de allocator wordt gebruikt. Een latere crash in free wijst de oorspronkelijke schrijfbewerking niet aan. ASan kan bij de schrijfbewerking stoppen wanneer de controles de grensoverschrijding detecteren.

Maak van tekens een geldige string

Een C-string eindigt met '\0'. De opslag heeft één byte meer nodig dan het aantal tekens. C accepteert char s[5] = "hello";, maar alle vijf bytes bevatten letters, zodat er geen afsluitend nulteken overblijft. Als je de array aan strlen of %s doorgeeft, kan er voorbij de array worden gelezen. Gebruik voldoende ruimte en zorg dat er daadwerkelijk een afsluitend nulteken aanwezig is. STR31-C gaat over capaciteit; STR32-C gaat over het doorgeven van een string met afsluitend nulteken.

Een stringliteral is niet beschrijfbaar. Na char *p = "hi"; is p[0] = 'H'; ongedefinieerd. Gebruik char p[] = "hi"; voor een beschrijfbare kopie, of const char *p om pogingen om de literal te veranderen zichtbaar te maken voor de compiler. Dit is STR30-C.

Respecteer levensduur en eigenaarschap

Controleer op NULL voordat je het resultaat van een geheugenallocatie, het openen van een bestand of een zoekactie derefereert. Wanneer een blok wordt vrijgegeven, verliest elke pointer naar een plaats daarin toegang tot een bestaand object. Lees of beschrijf het blok niet en geef het niet opnieuw vrij. Geef alleen de juiste pointer vrij die door een dynamische geheugenallocatie is teruggegeven, nooit een lokale array of een pointer naar een positie binnen een object. free(NULL) is onschadelijk, maar één pointer na vrijgave op nul zetten herstelt andere aliassen niet.

Een functie die het adres van een lokale array teruggeeft, geeft een ongeldige pointer naar een niet meer bestaand object terug:

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

De levensduur van de array eindigt wanneer de functie terugkeert. Laat de aanroepende functie een buffer en capaciteit doorgeven om te vullen, of reserveer een resultaat waarvan het eigenaarschap overgaat op de aanroepende functie. Een geslaagde afdruk direct na de terugkeer kan de levensduur van de oude array niet verlengen.

Reserveer bytes voor elk element

malloc(n) vraagt bytes aan, geen n objecten van het type waarnaar wordt verwezen. De gebruikelijke expressie op basis van elementen is n * sizeof *a. Voorkom eerst dat dat product modulair terugloopt:

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

Neem <stdint.h> op voor SIZE_MAX en <stdlib.h> voor allocatiefuncties. Als de grootte geldig is, reserveer je het geheugen, controleer je de teruggegeven pointer en schrijf je elke waarde voordat je die leest. malloc laat geheugen niet-geïnitialiseerd achter. calloc(n, sizeof *a) vult de opslag met nullen en gangbare bibliotheken wijzen producten af die overlopen. Een groottecontrole, een controle van het allocatieresultaat en een geldige index lossen verschillende problemen op; alle drie zijn van belang.

Een assertie legt iets vast wat waar hoort te zijn omdat je eigen code correct is. Een verborgen geschonden aanname wordt zo een stop dicht bij de plaats waar die aanname van belang is.

Controleer een programmeercontract

Neem <assert.h> op en schrijf assert(condition);. Bij een ware voorwaarde gaat de uitvoering door. Een onware voorwaarde drukt diagnostische informatie af naar stderr en roept abort() aan. De melding vermeldt de expressie, de broncodelocatie en de functie; de exacte formulering hangt af van het platform.

Voor een interne hulpfunctie voor gemiddelden waarvan de aanroepende functie geldige argumenten belooft:

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

Een onbedoelde aanroep met nul elementen faalt bij de geschonden belofte. Onder een debugger toont bt de assertie en de code voor het afbreken, gevolgd door de aanroepen in je code. Selecteer het stackframe van de aanroepende functie om te bekijken hoe die nul heeft doorgegeven.

Contracten komen op verschillende punten voor:

Een assertie is uitvoerbare documentatie: die benoemt de eigenschap en controleert die tijdens een testuitvoering. Kies expressies die de toestand bekijken zonder die te veranderen.

Houd noodzakelijke bewerkingen buiten asserties

Als je NDEBUG definieert voordat je <assert.h> opneemt, meestal met -DNDEBUG, wordt assert uitgeschakeld. De expressie wordt niet geëvalueerd. Dit veroorzaakt een ernstige programmeerfout als de expressie noodzakelijke bewerkingen uitvoert:

assert(++count <= MAX);

De incrementatie verdwijnt in een versie met NDEBUG. Schrijf de handeling afzonderlijk:

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

Dezelfde regel sluit het openen van bestanden, reserveren van geheugen of sluiten van bestanden binnen een assertie uit. Die bewerkingen moeten in alle configuraties plaatsvinden. Mislukkingen daarvan vereisen gewone foutafhandeling.

Handel verwachte fouten normaal af

Een ontbrekend invoerbestand, ongeldige gebruikerstekst en uitgeput geheugen kunnen bij correct gebruik van een programma voorkomen. Controleer ze met if, meld de fout en keer terug of ruim op. Een interne hulpfunctie kan een gevalideerd bereik met een assertie controleren, maar de openbare invoergrens moet dat bereik afdwingen met controles die in productieversies blijven bestaan.

Test bijvoorbeeld altijd fclose(f) == EOF in de gewone besturingsstroom wanneer je een uitvoerbestand sluit. Gebufferde uitvoer kan tijdens het sluiten mislukken; als je de aanroep of de controle verwijdert, kunnen verloren gegevens verborgen blijven.

Controleer vaste feiten tijdens het compileren

Een statische assertie test een constante expressie tijdens het compileren. In C17 biedt <assert.h> static_assert als macro voor _Static_assert uit C11:

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

Een onware voorwaarde laat het bouwproces mislukken. De assertie kan geen door een gebruiker ingevoerd aantal controleren dat pas tijdens de uitvoering bekend is. C23 maakt static_assert tot een sleutelwoord en staat toe de melding weg te laten. Gebruik dit onderscheid om elke controle te plaatsen waar de benodigde informatie beschikbaar is.

AddressSanitizer, meestal ASan genoemd, voegt controles toe aan gecompileerde geheugenbewerkingen. Het hulpmiddel kan ongeldige toegang melden op het moment dat die plaatsvindt, voordat beschadigde gegevens een crash op een andere plek veroorzaken.

Bouw en koppel met de controles

Gebruik GCC of Clang om met ASan te compileren en te koppelen:

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

-g levert broncodelocaties. Het behouden van framepointers helpt bij aanroepoverzichten. Instrumenteer bij een project met meerdere bestanden de relevante bronbestanden en gebruik de sanitizeroptie ook bij de laatste koppelstap. MSVC biedt /fsanitize=address voor ondersteunde Windows-versies.

ASan detecteert veel grensoverschrijdingen van heapblokken, arrays op de stapel en globale arrays. Het detecteert ook gebruik na vrijgave, dubbele vrijgave, ongeldige vrijgave en ondersteunde fouten door gebruik na het einde van een geldigheidsgebied. Op Linux bevat de gebruikelijke uitvoeringsomgeving van ASan lekcontrole bij het afsluiten. De meegeleverde Clang van Apple op macOS biedt die lekdetectie niet; LLVM-gereedschapsketens en platformondersteuning verschillen.

Volg een rapport naar de oorzaak

Neem een met succes gereserveerde array, met een int van 4 bytes:

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

De geheugenallocatie bevat 40 bytes. De indices nul tot en met negen gebruiken die bytes. Index tien begint direct daar voorbij. ASan kan “heap-buffer-overflow”, “WRITE of size 4” en een locatie nul bytes na een gebied van 40 bytes melden. Het overzicht van de schrijfbewerking wijst de toewijzing aan; het allocatieoverzicht wijst de malloc aan die de grenzen van het blok vastlegde.

Lees rapporten in deze volgorde:

1. Bepaal de foutcategorie en of de toegang een lees- of schrijfbewerking was.
2. Zoek in het toegangsoverzicht het eerste stackframe in je eigen code.
3. Vergelijk de toegang met het gereserveerde gebied en de elementgrootte.
4. Zoek bij een levensduurfout ook de overzichten van de allocatie en de vrijgave.

Hier is de oplossing i < 10. Als je nog een element reserveert en de verkeerde stopregel behoudt, verberg je het verschil tussen het bedoelde aantal en de lus. ASan stopt standaard bij de eerste gedetecteerde fout. Herstel die, bouw opnieuw en voer opnieuw uit.

Begrijp de grenzen van het controlehulpmiddel

ASan houdt toegestaan geheugen bij met schaduwgeheugen. Verboden geheugenzones omringen ondersteunde geheugenallocaties en arrays. Vrijgegeven blokken blijven vóór hergebruik een tijd in quarantaine, wat helpt om achterhaalde toegangen zichtbaar te maken. Een schrijfbewerking voorbij een arrayveld naar een ander veld van dezelfde struct kan binnen een groter geldig gebied blijven en aan detectie ontsnappen.

ASan controleert het gewoon lezen van niet-geïnitialiseerde waarden niet. Memcheck van Valgrind kan dat gebruik en veel heapfouten zonder opnieuw compileren vinden, maar is doorgaans ongeveer 20 tot 30 keer zo langzaam. ASan vertraagt doorgaans ongeveer twee keer en gebruikt extra geheugen. Combineer een ASan-versie niet met Valgrind, MemorySanitizer of ThreadSanitizer. Voer bewust grensgevallen als invoer uit: een fout op een niet-uitgevoerd pad kan niet in het rapport verschijnen.

Een geheugencontrolehulpmiddel dekt niet elke ongeldige C-bewerking. UndefinedBehaviorSanitizer, of UBSan, instrumenteert veel bewerkingen met berekeningen, pointers en arrays. Combineer het met ASan zodat een testuitvoering meer dan één soort fout kan detecteren.

Maak rekenfouten zichtbaar

Bij een 32-bits int levert het optellen van twee waarden van 2.000.000.000 een totaal van 4.000.000.000 op. Dat resultaat is groter dan INT_MAX. Een UBSan-rapport wijst overloop bij gehele getallen met teken aan bij de optelling en noemt de operanden. Het afdrukken van een negatief antwoord dat op terugloop lijkt zonder het controlehulpmiddel zou de bewerking niet geldig maken.

Gebruik voor het totaal een type dat het geaccepteerde bereik kan voorstellen, of wijs een optelling af voordat die overloopt. Het al overgelopen resultaat converteren naar long long is te laat; de bewerking zelf moet een geschikt type gebruiken.

Een gebruikelijke testopdracht is:

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

UBSan staat normaal gesproken herstel na veel meldingen toe, zodat latere code kan doorgaan. -fno-sanitize-recover=undefined laat die fouten de test stoppen met een foutstatus. Dat helpt geautomatiseerde controles een programmeerfout te detecteren, ook wanneer de uiteindelijke afgedrukte uitvoer juist lijkt.

Kies het hulpmiddel bij de fout

Modulaire terugloop bij gehele getallen zonder teken is gedefinieerd, dus de groep undefined meldt die niet. Clang heeft een afzonderlijke controle -fsanitize=unsigned-integer-overflow voor code waarin terugloop op een programmeerfout wijst. Leid hieruit niet af dat elk ongewenst geheelgetalresultaat ongedefinieerd gedrag is.

MemorySanitizer is een hulpmiddel van Clang dat vooral op Linux wordt gebruikt; niet-geïnstrumenteerde bibliotheken kunnen de tracering ervan verstoren. ThreadSanitizer detecteert conflicterende toegangen door threads zonder synchronisatie, met minstens één schrijfbewerking. De toegangen hoeven niet op exact hetzelfde moment plaats te vinden. Geen van beide hulpmiddelen kan in één versie met ASan worden gecombineerd.

Maak van controleren een routine

Houd waarschuwingen ingeschakeld en los ze op. Bouw met ASan en UBSan en voer vervolgens lege invoer, invoer met één element, volle buffers, ongeldige tekst en waarden dicht bij de geaccepteerde grenzen uit. Voer statische analyse uit om paden te onderzoeken die de tests kunnen missen en herhaal de controles automatisch wanneer code verandert. Voer ook de productieconfiguratie uit, waarin optimalisatie en assertie-instellingen verschillen.

Fuzzing levert veel gegenereerde of gewijzigde invoer. libFuzzer en AFL++ kunnen ongebruikelijke paden in parsers blootleggen; sanitizers zetten een veroorzaakte ongeldige bewerking om in een bruikbaar rapport. Bewaar invoer die een fout vindt, minimaliseer die zonder het falen te verliezen, herstel de oorzaak en bewaar de invoer als regressietest. Een uitvoering zonder meldingen is bewijs over de uitgevoerde invoer, geen garantie voor alle mogelijke uitvoeringen.

Een standaard voor veilig programmeren verzamelt concrete regels die terugkerende fouten voorkomen. Die geeft een beoordelaar nuttigere vragen dan “Ziet dit er veilig uit?” Elke regel verbindt een risicovolle bewerking met de voorwaarde of het ontwerp dat nodig is om die veilig te maken.

Lees een regel om de reden te begrijpen

De SEI CERT C Coding Standard komt van het Software Engineering Institute van Carnegie Mellon University. Naast de boekeditie uit 2016 bestaat een online versie die verder wordt ontwikkeld. De standaard onderscheidt regels, waarvan overtreding waarschijnlijk fouten veroorzaakt, en aanbevelingen die de betrouwbaarheid en beveiliging verbeteren.

Identifiers combineren een categorie, een getal en -C. Regels gebruiken de nummers 30–99; aanbevelingen gebruiken 00–29. Zo gaat INT32-C over overloop bij gehele getallen met teken, terwijl DCL00-C een aanbeveling over declaraties is. Categorieën omvatten declaraties (DCL), expressies (EXP), gehele getallen (INT), drijvende komma (FLP), arrays (ARR), strings (STR), geheugen (MEM), invoer en uitvoer (FIO), omgeving (ENV), fouten (ERR) en overige onderwerpen (MSC).

Een regelpagina legt normaal gesproken de fout uit, toont code die niet aan de regel voldoet, presenteert oplossingen die eraan voldoen en beoordeelt het risico. Lees de aannames van elke oplossing. Een vervangende functie is alleen nuttig wanneer het gedrag daadwerkelijk aan de eis voldoet.

Pas een regel toe op een gegevenspad

FIO30-C gaat over formaatstrings. Deze code behandelt gegevens van buitenaf als een opmaakprogramma:

printf(user_name);

Een gebruikersnaam met formaatconversies laat printf zoeken naar argumenten die niet zijn doorgegeven; %n kan een schrijfbewerking in het geheugen veroorzaken. Houd het formaat onder controle van het programma:

printf("%s", user_name);

Als alternatief drukt fputs(user_name, stdout) de tekst af zonder opmaakverwerking. -Wformat=2 bevat controles die onveilige formaten helpen vinden. De oplossing verandert hoe gegevens worden geïnterpreteerd, niet alleen hoe lang de string mag zijn.

Maak een nuttige controlelijst

Vraag bij geheugen of indices binnen objecten blijven (ARR30-C), stringopslag het afsluitende nulteken bevat (STR31-C), vrijgegeven opslag nooit wordt benaderd (MEM30-C), geheugenallocaties waarvan de code eigenaar is worden vrijgegeven (MEM31-C), alleen geldige geheugenallocaties worden vrijgegeven (MEM34-C) en genoeg bytes worden gereserveerd (MEM35-C).

Controleer bij expressies op onbedoelde modulaire terugloop bij getallen zonder teken (INT30-C), overloop bij getallen met teken (INT32-C), ongeldige deling (INT33-C), het lezen van niet-geïnitialiseerde waarden (EXP33-C) en het derefereren van nulpointers (EXP34-C). Handel bij bibliotheekaanroepen gemelde fouten (ERR33-C) en conversiefouten (ERR34-C) af. Vermijd system() volgens ENV33-C, omdat een shell de invoer ervan interpreteert.

Risicotabellen beoordelen ernst, waarschijnlijkheid en herstelkosten van 1 tot en met 3; een hogere kostenscore betekent goedkoper herstel. Het product is de prioriteit, van 1 tot en met 27. Niveaus groeperen prioriteiten in L1 (12–27), L2 (6–9) en L3 (1–4). Dit helpt herstelwerk te ordenen zonder fouten met lagere prioriteit onschadelijk te verklaren.

Gebruik regels tijdens codebeoordeling en gebruik bevindingen van analysetools die aan hun identifiers zijn gekoppeld. MISRA C is een andere standaard die wordt gebruikt bij veiligheidskritiek ingebed werk. Regels helpen fouten te voorkomen, terwijl waarschuwingen, tests en sanitizers controleren of de implementatie ze daadwerkelijk volgt. Alleen identifiers onthouden kan geen ontbrekend afsluitend nulteken of overgeslagen fouttak detecteren.

Veilig omgaan met strings vereist een geldige bron, een bekende capaciteit van de bestemming en een beslissing over tekst die niet past. Een functie met een groottelimiet voorkomt sommige overschrijvingen, maar je moet nog steeds controleren of de hele bewerking is geslaagd.

Geef de capaciteit mee met de pointer

sizeof meet het type van de operand. Voor een lokale char buf[20] levert dit 20 bytes op. In void fill(char buf[]) wordt de parameter omgezet naar een pointer; sizeof buf meet die pointer, niet de array van de aanroepende functie. Geef een capaciteitsparameter door, zoals in fill(buf, sizeof buf), terwijl de aanroepende functie nog over het arraytype beschikt.

Een string met vijf tekens heeft zes bytes nodig, inclusief '\0'. De capaciteit telt elke beschrijfbare byte mee; de stringlengte sluit het afsluitende nulteken uit. Daarom reserveert malloc(strlen(src)) één byte te weinig voor een kopie.

Lees een regel binnen de grenzen

Gebruik fgets(buf, sizeof buf, stdin) en controleer de retourwaarde voordat je de inhoud gebruikt. De functie slaat hoogstens de capaciteit min één tekens op, gevolgd door een afsluitend nulteken. Een regelafbrekingsteken blijft behouden wanneer het past. Na een geslaagde leesbewerking verwijdert buf[strcspn(buf, "\n")] = '\0'; een opgeslagen regelafbrekingsteken.

Als een lange regel de buffer vult, blijven ongelezen tekens over voor de volgende aanroep. Beslis of je de rest afwijst en uitleest, meer leest of afkapping accepteert. Een regelafbrekingsteken verwijderen bewijst niet dat je de volledige regel hebt gelezen. gets kan geen capaciteit ontvangen en is in C11 verwijderd; gebruik die functie nooit.

Voor één woord in char name[20] beperkt %19s in scanf het aantal opgeslagen tekens en blijft ruimte over voor het afsluitende nulteken. Controleer of het verwachte aantal conversies is geslaagd. Lees voor niet-vertrouwde numerieke tekst bij voorkeur een volledige regel, gevolgd door een gecontroleerde strtol; %d heeft ongedefinieerd gedrag wanneer de geconverteerde waarde niet kan worden weergegeven, ook als je het door scanf teruggegeven aantal controleert.

Detecteer een verkorte kopie

strcpy en strcat kennen de capaciteit van de bestemming niet. strncpy kan het resultaat zonder afsluitend nulteken achterlaten. Bij een positieve capaciteit sluit snprintf de opgeslagen tekst af en meldt het hoeveel tekens de volledige uitvoer nodig had:

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 */
}

De opgeslagen string is “debuggi” en r is 9. De volledige uitvoer heeft tien bytes nodig inclusief het afsluitende nulteken. Controleer of het resultaat negatief is voordat je het naar size_t converteert. Een passend resultaat vereist dat r kleiner is dan de capaciteit.

Stem de bewerking af op de opslag

Gebruik memmove wanneer bron en bestemming overlappen; memcpy met overlap is ongedefinieerd. strlcpy is beschikbaar op BSD-systemen, macOS en vanaf glibc 2.38, maar is geen ISO C. Functies uit bijlage K zijn optioneel en in veel bibliotheken niet beschikbaar.

Houd gebruikersgegevens uit het formaat zelf. Stem elke conversie af op het argument: %d voor int, %ld voor long, %zu voor size_t, %f voor double en %s voor een string met afsluitend nulteken. %p vereist een void *, dus geef een geschikte pointerconversie door. Een breedtelimiet kan een niet-passend argumenttype niet herstellen.

Gegevens van buitenaf kunnen syntactisch geldig zijn en toch onveilig voor de bewerking die je wilt uitvoeren. Valideer de lengte, het volledige formaat en het bruikbare bereik voordat je de gegevens gebruikt als index, allocatiegrootte of aantal lusiteraties.

Verwerk het hele getal

atoi biedt geen betrouwbare manier om een geldige nul te onderscheiden van ongeldige tekst, en een resultaat dat niet kan worden weergegeven veroorzaakt ongedefinieerd gedrag. strtol biedt een eindpointer en een bereikfout. Na het lezen van een volledige regel en het verwijderen van het regelafbrekingsteken kan een strikte parser voor decimale getallen dit gebruiken:

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 */
}

Neem <errno.h> en <stdlib.h> op. De eerste test onderscheidt drie fouten: geen cijfers, tekst aan het einde en een waarde buiten het bereik van long. De controle van het toepassingsbereik komt vóór de conversie naar het smallere type int. strtol accepteert voorafgaande spaties en een optioneel teken; bepaal of de grammatica van de toepassing die toestaat.

Voor “42abc” kan de conversie 42 teruggeven, maar end wijst naar de resterende letters. Voor “abc” worden geen cijfers verwerkt. Voor een te groot decimaal geheel getal wordt errno gelijk aan ERANGE. Alleen een teruggegeven getal dat niet nul is, bewijst noch dat de conversie volledig is, noch dat de waarde binnen een veilig bereik valt.

Behoud eigenaarschap bij een fout

Elke bewerking die kan mislukken, vereist een reactie. Controleer allocatieresultaten, fopen, fgets, aantallen geslaagde conversies en of uitvoer is voltooid. Als fgets NULL teruggeeft, kan dat het einde van de invoer of een leesfout betekenen. fclose kan melden dat een gebufferde schrijfbewerking is mislukt. Gebruik foutinformatie die bij de functie past; veel bibliotheekaanroepen stellen errno in, dat perror of strerror kan omzetten in een leesbare diagnostische melding.

Bescherm bij het wijzigen naar een positieve grootte de grootteberekening en de oorspronkelijke geheugenallocatie:

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;
    }
}

Als je het resultaat van realloc rechtstreeks toewijst aan de enige pointer die eigenaar is, verlies je bij een mislukking het adres van het oude blok. Handel nul afzonderlijk af: C17 maakt realloc met grootte nul door de implementatie bepaald, terwijl C23 dit ongedefinieerd maakt. Gebruik na een geslaagde groottewijziging de teruggegeven pointer en gebruik achterhaalde aliassen niet meer.

Zorg voor een duidelijk foutpad

Eén opruimsectie kan verkregen hulpbronnen in omgekeerde volgorde vrijgeven. Initialiseer pointers waarvan de code eigenaar is op NULL, sluit alleen geopende bestanden en geef een foutstatus terug nadat je de oorzaak hebt gemeld. Een goto cleanup kan deze paden gemakkelijker controleerbaar maken.

Vermijd system() voor taken met tekst van buitenaf: de shell kan die tekst als opdrachten interpreteren. Gebruik bij voorkeur een bibliotheekbewerking of een geschikte interface om een programma te starten waarbij argumenten afzonderlijk worden doorgegeven. Behandel opdrachtregelargumenten, omgevingswaarden, bestandsinhoud en netwerkgegevens als invoer die dezelfde zorg vereist als ingetypte tekst.

Geheugenveiligheid betekent dat geheugentoegang binnen de opslag blijft die een programma mag gebruiken. C geeft directe controle over het geheugen en laat controles van grenzen en levensduur aan de programmeur over.

Onderscheid grenzen van tijd

Ruimtelijke geheugenveiligheid houdt een toegang binnen de grenzen van het object. Element tien van een array met tien elementen schrijven schendt die veiligheid. Temporele geheugenveiligheid houdt toegang binnen de levensduur van het object. Een geheugenallocatie lezen na free, die tweemaal vrijgeven of een teruggegeven lokaal adres gebruiken schendt de regels voor levensduur.

De gevolgen kunnen verder gaan dan een crash. Een leesbewerking kan vertrouwelijke gegevens blootleggen. Een schrijfbewerking kan een bestand beschadigen, besturingsgegevens veranderen of een beveiligingskwetsbaarheid creëren wanneer invoer van buitenaf de bewerking stuurt. Een programma dat na beschadiging doorgaat, kan overtuigende maar onjuiste resultaten opleveren.

Deze last treft ook ervaren teams. Microsoft meldde in 2019 dat meer dan een decennium lang, jaar na jaar, ongeveer 70% van de kwetsbaarheden waaraan het bedrijf CVE-identifiers had toegekend over geheugenveiligheid ging. In december 2023 riepen CISA en partnerinstanties softwaremakers op om een overstap naar geheugenveilige programmeertalen te plannen. Dit zijn specifieke historische waarnemingen, geen gemeten percentage voor elk C-programma.

Begrijp waarom je C zou kiezen

C biedt controle over indeling, geheugenallocatie en toegang tot hardware, zonder een garbagecollector te vereisen. De kleine uitvoeringsomgeving past bij firmware met beperkte middelen. Er is brede compilerondersteuning, er zijn grote bestaande codebases en veel andere talen kunnen de interfaces aanroepen. Deze voordelen verklaren het gebruik in besturingssysteemkernen, ingebedde software, uitvoeringsomgevingen en bibliotheken.

Ze maken niet elk C-programma voorspelbaar snel: algoritmen, geheugenallocatie, caches en systeemaanroepen blijven van belang. Het relevante voordeel is controle over kosten en eisen aan de uitvoeringsomgeving.

Onveilige bewerkingen en interfaces met C vereisen bijzondere zorg in verder geheugenveilige systemen. Ook bij geheugenveiligheid moeten logische fouten en injectie via invoer nog worden aangepakt.

Kies lagen voor het resterende risico

Voorkom fouten met programmeerregels, waarschuwingen en codebeoordeling. Detecteer fouten met statische analyse, grenswaardetests, sanitizers en fuzzing. Beperk resterende schade met stapelbeveiliging, ondersteunde controles van _FORTIFY_SOURCE, randomisatie van de adresruimte-indeling (ASLR) en niet-uitvoerbaar geheugen. Een beschermingsmaatregel kan een aanval stoppen of beschadiging in een crash veranderen terwijl de fout in de broncode blijft bestaan.

Kosten bepalen waar je hulpmiddelen inzet. ASan verdubbelt doorgaans de uitvoeringstijd en verhoogt het geheugengebruik; Valgrind vertraagt de uitvoering doorgaans 20 tot 30 keer. Ze passen beter bij testen dan bij gewoon gebruik van productieversies. Beveiligingsversterking met lagere kosten blijft vaak in productieversies aanwezig.

Voor een nieuwe parser voor internetbestanden zonder eis die C vereist, vermindert een geheugenveilige programmeertaal een groot risico. Voor bestaande C-firmware op een microcontroller met 32 KB geheugen kunnen taalondersteuning en beperkte middelen pleiten voor C met strenge controles. Baseer de keuze op beperkingen, blootstelling aan invoer en onderhoudbaarheid; een risicovolle parser geleidelijk vervangen kan ook praktisch zijn.