Débogage, comportements indéfinis et programmation C sécurisée

Les avertissements te donnent l’occasion de corriger un défaut avant qu’une entrée ne le déclenche. Une erreur empêche la compilation de réussir. Un avertissement permet à la compilation de continuer, mais signale un point que tu dois comprendre : du code valide mais suspect, un comportement potentiellement indéfini ou une violation des règles du langage que le compilateur accepte.

Choisir des vérifications utiles

Lance GCC ou Clang en indiquant explicitement la version du langage et un large ensemble d’avertissements :

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

-Wall active de nombreuses vérifications courantes, mais pas tous les avertissements. -Wextra en ajoute d’autres, dont les comparaisons entre valeurs signées et non signées en C. -Wpedantic signale de nombreux écarts par rapport à la norme ISO choisie ; ce n’est pas un test complet de conformité. L’option /W4 de MSVC remplit un rôle similaire sous Windows.

Ajoute des vérifications adaptées aux risques présents dans ton code :

Par exemple, double price = 3.7; int whole = price; supprime la partie fractionnaire. -Wconversion rend cette conversion visible. Si la troncature est voulue et que la valeur est représentable, (int)price explicite ce choix. Si la partie fractionnaire compte, conserve un type à virgule flottante. Pour arrondir à l’entier le plus proche, lround de <math.h> a un rôle différent d’une conversion explicite.

Lire le premier message utile

Un diagnostic indique normalement un emplacement dans le code source, un message et l’option d’avertissement. Un accent circonflexe marque l’expression concernée ; les notes qui suivent peuvent indiquer une déclaration ou suggérer une correction. Lis tout le groupe de messages. Si une erreur de syntaxe provoque de nombreux messages ultérieurs, corrige la première erreur et recompile avant d’examiner les autres.

Supposons qu’un programme contienne ces trois lignes, avec average déclaré comme double :

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

L’affectation dans la condition donne à count la valeur zéro, ce qui rend la condition fausse. Si l’intention était de faire une comparaison, utilise count == 0. Ajouter des parenthèses autour de l’affectation peut faire disparaître un avertissement tout en laissant le bogue intact.

Le format %d attend un int, mais l’argument est un double. Utilise %f ; une incompatibilité de format est un comportement indéfini, pas une demande de conversion de la valeur. Supprime la déclaration inutilisée si elle ne sert à rien. Ces trois problèmes ont des causes différentes et demandent donc chacun leur propre correction.

Suivre les indices

Prête une attention particulière aux valeurs non initialisées, aux retours manquants, aux adresses de variables locales renvoyées et à l’utilisation de sizeof sur les paramètres tableaux. Un fichier d’en-tête manquant peut laisser une fonction non déclarée ; les versions récentes de GCC et Clang rejettent cela par défaut. N’ajoute pas une conversion explicite simplement pour faire disparaître un diagnostic. Explique d’abord les types et les valeurs attendus, puis écris le code de façon à exprimer cette intention.

Un programme sans avertissement peut malgré tout avoir une condition de boucle incorrecte ou utiliser un indice invalide fourni en entrée. Certains avertissements dépendent aussi de l’optimisation et de l’analyse du flux de données, et les compilateurs détectent des cas différents. Garde les avertissements activés dans les compilations ordinaires, puis examine le comportement à l’exécution avec le débogueur et les outils de test.

Un même code source peut être compilé pour faciliter son inspection, effectuer des tests intensifs ou produire une version de production efficace. Les paramètres de compilation déterminent les informations visibles et les vérifications supplémentaires exécutées. Donne un objectif clair à chaque version compilée.

Conserver les informations sur le code source

L’option -g ajoute les noms, les types et les correspondances entre les instructions machine et les lignes source. Elle permet à un débogueur d’afficher ton code et aide les rapports des sanitizers à indiquer les emplacements. Elle n’active pas de vérifications à l’exécution et ne désactive pas l’optimisation. Sans informations de débogage, certains noms de fonctions peuvent rester disponibles, mais les lignes source et les variables locales sont beaucoup plus difficiles à retrouver.

L’optimisation modifie la fidélité avec laquelle l’exécution suit l’ordre du code source :

Une session de débogage sur du code optimisé peut sauter des lignes ou afficher une variable sous la forme «  ». Le compilateur a préservé le comportement du code défini, mais il peut ne plus conserver toutes les valeurs intermédiaires présentes dans le code source. -O0 ne traduit pas littéralement chaque ligne C en une seule instruction machine.

Compiler selon l’objectif

Une commande simple pour le débogage est :

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

Une version de test ajoute des sanitizers. Une version de production utilise couramment -O2 et peut définir NDEBUG pour supprimer les assertions. La validation ordinaire des entrées et la gestion des erreurs doivent rester actives lorsque les assertions disparaissent. Teste aussi la configuration de production : un problème visible uniquement avec l’optimisation est une raison sérieuse de rechercher un comportement indéfini, notamment des lectures de valeurs non initialisées et des débordements d’entiers signés.

Conserve les options communes dans un Makefile ou une autre configuration de compilation. Des noms de sortie distincts évitent d’exécuter par accident un ancien exécutable de production pendant que tu inspectes le code source récemment modifié. Après chaque modification du code source, recompile l’exécutable que tu comptes lancer.

Ajouter l’analyse et le durcissement

L’analyse statique suit les chemins possibles dans le code source sans exécuter le programme. Essaie gcc -fanalyzer ou clang --analyze ; scan-build, clang-tidy et cppcheck offrent d’autres méthodes d’analyse. Un analyseur peut remarquer qu’une branche de gestion d’erreur libère deux fois un pointeur, même si tes tests ne passent jamais par cette branche. Examine son raisonnement : l’analyse des chemins possibles peut produire de fausses alertes.

L’analyse dynamique vérifie l’exécution réelle. Les sanitizers et Valgrind ne voient que les chemins parcourus : leur couverture dépend donc de tes entrées. Combine les deux types d’analyse.

Le durcissement en production limite les dommages causés par les défauts restants. -fstack-protector-strong place des vérifications dans certains cadres de pile pour détecter de nombreux écrasements. Sur les systèmes qui le prennent en charge, _FORTIFY_SOURCE ajoute des vérifications aux appels de bibliothèque lorsque les tailles des objets peuvent être déterminées. Il nécessite l’optimisation ; le niveau 2 est courant, tandis que le niveau 3 nécessite une prise en charge adaptée par le compilateur et la bibliothèque C. Ce sont des fonctionnalités propres aux plateformes, pas des garanties d’ISO C.

Un programme durci peut s’arrêter lorsqu’il détecte une corruption. L’opération invalide doit quand même être corrigée dans le code source ; modifier les options de production ne peut pas corriger une boucle qui dépasse les limites d’un tableau.

Une défaillance est le comportement que tu observes : un plantage, un total incorrect ou une sortie qui n’apparaît jamais. Un bogue est l’erreur qui l’a causée. Distinguer les deux évite de modifier la ligne du plantage avant de comprendre comment le programme y est arrivé.

Rendre la défaillance reproductible

Note la commande, les données d’entrée, les options de compilation, le résultat attendu et le résultat obtenu. Garde l’entrée qui provoque l’échec inchangée pendant tes expériences. Si un programme échoue uniquement avec un fichier, sauvegarde ce fichier avant de le modifier. La reproduction te permet de juger si une correction proposée fonctionne.

Réduis ensuite le cas tout en conservant la défaillance. Supprime les enregistrements ou le code sans rapport avec le problème et relance le programme. Supposons qu’un enregistrement parmi 1 000 déclenche à lui seul un plantage. Essayer les moitiés permet de le trouver en 10 étapes environ. Si aucune moitié ne provoque la défaillance seule, celle-ci peut nécessiter une suite d’enregistrements ou un état accumulé auparavant. Conserve cette suite et retire de plus petits morceaux autour d’elle. La division en deux n’est utile que si l’entrée conservée sollicite encore la cause du problème.

Poser une question vérifiable

Un champ vide dans un fichier réduit suggère une hypothèse : « L’analyseur utilise le champ avant de vérifier s’il existe. » Teste-la avec une petite entrée contenant un champ vide. Inspecte le pointeur renvoyé ou ajoute une vérification ciblée. Modifie une seule chose à la fois ; si tu modifies simultanément l’analyseur, la taille du tampon et l’entrée, une réussite ne t’indiquera pas quelle modification a compté.

Corrige la règle enfreinte, relance le cas réduit, puis relance l’entrée initiale et les tests existants. Conserve le cas déclencheur comme test de non-régression pour qu’une modification ultérieure ne puisse pas réintroduire silencieusement la même défaillance.

Interpréter l’arrêt

« Segmentation fault » indique généralement SIGSEGV : le système a arrêté un accès mémoire invalide. Un pointeur nul, un pointeur libéré ou une adresse hors limites en est une cause fréquente. Un accès invalide peut aussi ne pas provoquer de plantage immédiat : l’absence de message ne suffit donc pas à conclure.

« Aborted » indique généralement SIGABRT, déclenché par abort(). Une assertion qui échoue ou une vérification de bibliothèque qui détecte une corruption du tas peut en être la cause. Dans bash, les codes de retour courants associés aux signaux sont 139 pour SIGSEGV et 134 pour SIGABRT ; ce sont des conventions de l’interpréteur de commandes, pas des valeurs de retour C que ton programme doit utiliser.

Observer sans perdre la sortie

Un court message de diagnostic peut révéler la première valeur incorrecte :

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

Les indications rendent la sortie lisible lorsque la même ligne s’exécute de nombreuses fois. stderr est utile pour les diagnostics car il n’est pas entièrement mis en tampon ; stdout redirigé vers un fichier ou un tube est normalement entièrement mis en tampon, si bien qu’un plantage peut faire perdre la sortie en attente. Supprime les affichages temporaires après la correction.

Explique à voix haute une fonction suspecte, ligne par ligne. Cette méthode du « canard en plastique » t’oblige à confronter chaque opération au comportement attendu. Si un bogue change lorsque tu ajoutes des affichages ou modifies l’optimisation, recherche un comportement indéfini avec les sanitizers. Agrandir un tableau jusqu’à ce qu’un plantage disparaisse peut masquer un indice invalide sans le corriger.

Un débogueur te permet de suspendre un programme en cours d’exécution et d’inspecter les valeurs qui expliquent son comportement. Utilise GDB sur de nombreux systèmes Linux ou LLDB sur macOS. Les boutons de débogage des environnements de développement intégrés reposent sur les mêmes principes : arrêter, exécuter, inspecter et avancer pas à pas.

Partir du bon exécutable

Compile avec -g -O0, puis ouvre le résultat avec gdb ./program ou lldb ./program. À l’invite, run records.txt 3 le lance avec deux arguments. Dans GDB, run < input.txt redirige l’entrée standard ; dans LLDB, utilise process launch -i input.txt. Utilise quit pour quitter.

Place un point d’arrêt avant l’exécution. break main dans GDB et b main dans LLDB arrêtent le programme au début de main. Les deux acceptent un emplacement composé d’un fichier et d’une ligne, comme b program.c:12. Les commandes complètes de LLDB comprennent breakpoint set --name main et breakpoint set --file program.c --line 12.

Un point d’arrêt suspend normalement le programme avant l’exécution de l’instruction source indiquée. Si la ligne sélectionnée affecte une valeur, affiche celle-ci après avoir exécuté la ligne pour inspecter sa nouvelle valeur. Recompile après toute modification du code source : le débogueur exécute le code machine, pas le texte ouvert dans ton éditeur.

Choisir comment avancer

D’autres points d’arrêt peuvent interrompre next ou finish. Utilise next pour un appel de bibliothèque que tu n’as pas besoin d’inspecter. Si tu entres dans du code que tu ne souhaites pas examiner, finish rend le contrôle à la fonction appelante.

Inspecter une boucle à chaque passage

Considère une somme initialisée à zéro et ce tableau :

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

Arrête-toi dans le corps de la boucle et affiche i et sum avant l’addition. Après les cinq premières additions, les sommes successives sont 4, 12, 27, 43 et 66. À l’arrêt suivant, i == 5, mais les indices valides s’arrêtent à 4. Tu as trouvé l’itération supplémentaire sans avoir besoin de lire l’élément invalide. Remplace la condition par i < 5, recompile et relance le programme.

print expr ou p expr évalue une expression dans les deux débogueurs. Commence par des observations sûres comme p i et p sum ; une expression du débogueur qui déréférence un pointeur invalide peut elle-même tenter une lecture invalide. display i dans GDB répète l’affichage à chaque arrêt. info locals dans GDB et frame variable dans LLDB affichent les variables locales. Pour cinq éléments valides accessibles par ptr, utilise p *ptr@5 dans GDB ou parray 5 ptr dans LLDB.

Tu peux tester une hypothèse en modifiant une valeur pendant la suspension : GDB accepte set var i = 4, tandis que LLDB accepte expr i = 4. Cela modifie une exécution, pas le code source. Pour gérer les points d’arrêt, utilise info breakpoints et delete 1 dans GDB, ou breakpoint list et breakpoint delete 1 dans LLDB.

Un plantage dans une bibliothèque commence souvent par un argument invalide provenant de ton propre code. La pile d’appels montre les appels de fonctions actifs. Utilise-la pour passer du lieu de l’arrêt à la fonction appelante dont tu peux expliquer les valeurs.

Lire les cadres en remontant depuis l’appel courant

Saisis bt dans l’un ou l’autre débogueur. Le cadre #0 correspond à l’appel actif le plus profond ; les cadres de numéro supérieur sont ses fonctions appelantes. Un cadre fournit le contexte d’exécution de la fonction, notamment les arguments et les variables locales disponibles. L’optimisation peut supprimer certaines de ces informations.

Supposons que find_name(2) ne trouve aucune correspondance et que la fonction appelante fasse ceci :

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

L’arrêt peut se produire dans strlen. Dans bt, trouve le premier cadre appartenant à ton code. S’il s’agit du cadre 1, sélectionne-le avec frame 1 dans GDB ou frame select 1 dans LLDB. Affiche name. Une valeur nulle explique pourquoi l’opération sur la chaîne a échoué. La fonction appelante doit gérer l’absence de nom avant d’appeler strlen ; modifier la bibliothèque ne peut pas corriger l’argument.

Utilise up et down pour te déplacer entre les fonctions appelantes et appelées. Sélectionner un cadre modifie ce que le débogueur affiche et les variables locales auxquelles une expression fait référence. Cela ne reprend pas l’exécution et n’annule pas un appel.

S’arrêter là où une valeur change

Un point d’arrêt pose la question : « Que se passe-t-il à cet endroit ? » Un point de surveillance demande : « Quelle opération change cette valeur ? » Si un nombre stocké devient incorrect bien avant un plantage, suspends le programme tant que ce nombre est dans la portée et utilise :

GDB:  watch count
LLDB: watchpoint set variable count

Poursuis jusqu’à ce que le débogueur s’arrête sur un changement. Inspecte l’ancienne et la nouvelle valeur ainsi que l’emplacement source de l’instruction d’écriture. Un changement peut être légitime : compare-le donc à la règle de la structure de données. Le matériel n’offre qu’un petit nombre de points de surveillance ; quatre sont courants sur x86-64. Le stockage d’une variable locale n’a de sens que tant que sa fonction est active.

Pour une itération tardive connue, utilise un point d’arrêt conditionnel. break 20 if i == 999 dans GDB suspend le programme à la ligne 20 uniquement lorsque la condition est vraie. Son équivalent dans LLDB est breakpoint set --line 20 --condition 'i == 999'. Cela évite des centaines d’étapes manuelles.

Inspecter un plantage enregistré

Un vidage mémoire enregistre l’état d’un processus qui a planté. Là où les vidages mémoire sont activés, ulimit -c unlimited les autorise pour les programmes lancés depuis cet interpréteur de commandes. Ouvre un vidage enregistré avec gdb ./program core ou lldb ./program -c core, en utilisant l’exécutable qui l’a produit. Les règles du système déterminent si un vidage est enregistré et où il est placé ; les systèmes Linux utilisant systemd peuvent le gérer avec coredumpctl.

Exécute bt, sélectionne ton cadre et inspecte les valeurs comme lors d’un plantage en direct. Le vidage ne permet pas de reprendre l’exécution du programme. Si malloc ou free détecte une corruption, l’écriture incorrecte initiale peut être absente de cette pile. Reproduis le problème avec AddressSanitizer pour arrêter le programme plus près de cette écriture. Si une valeur locale semble arbitraire, vérifie si l’exécution a atteint son initialisation avant de mettre en cause le débogueur.

Un comportement indéfini signifie que la norme C n’impose aucune exigence sur ce qui se produit après une opération invalide. Elle ne promet ni exception, ni message d’erreur utile, ni valeur rebouclée prévisible. Un programme peut planter, corrompre des données, afficher une réponse plausible ou sembler fonctionner.

Distinguer trois types de comportements

Un comportement défini par l’implémentation peut être utilisé délibérément lorsque la plateforme documentée fait partie de la conception d’un programme. Pour obtenir du code portable, ne suppose pas que toutes les implémentations font le même choix. Un comportement non spécifié est également valide : f(a(), b()) peut évaluer d’abord l’un ou l’autre des appels indépendants. Écris du code qui reste correct malgré cette variation autorisée. La largeur de int et, en C17, le décalage à droite d’un entier signé négatif sont d’autres choix qui dépendent de la plateforme.

Pourquoi l’optimisation révèle des bogues

C laisse au programmeur les vérifications des bornes des tableaux et des additions d’entiers signés. Le compilateur peut optimiser le code en supposant que le programme respecte les règles du langage. Une tentative de détection de débordement peut enfreindre la règle même qu’elle cherche à vérifier :

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

Pour toute valeur de x pour laquelle l’addition d’entiers signés est définie, x + 1 est supérieur à x. Le compilateur peut donc remplacer le résultat par zéro. À la valeur INT_MAX, l’addition a un comportement indéfini : le compilateur ne doit donc aucun résultat rebouclé à la fonction appelante. Observer une réponse différente dans une version non optimisée ne rend pas ce test valide.

Le test sûr s’effectue avant l’opération :

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

Utilise <limits.h> pour connaître les limites de l’implémentation. Un maximum écrit en dur suppose une largeur de type particulière ; la macro désigne la limite réelle.

Placer les vérifications avant la première utilisation

Cet ordre est également essentiel pour les pointeurs :

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

Inverser ces instructions permettrait le déréférencement d’un pointeur nul avant la protection. Dès que le code déréférence p, un optimiseur peut raisonner que le chemin défini exige déjà que p soit non nul et supprimer un test ultérieur de nullité.

Modifier les options, ajouter un affichage ou déplacer une variable peut changer le symptôme visible d’un comportement indéfini. Une exécution réussie établit seulement ce que cette version compilée a fait pour cette entrée. Pour corriger le code, détermine quelle opération n’a pas de sens défini et quelle condition doit être vraie avant son exécution. Les avertissements peuvent repérer certains cas ; l’analyse statique peut explorer les chemins possibles ; ASan et UBSan vérifient de nombreuses opérations exécutées. Les règles de programmation fournissent les méthodes correspondantes dans le code source, comme vérifier un indice ou une borne arithmétique avant de l’utiliser.

Un calcul peut échouer avant que tu aies la possibilité d’en inspecter le résultat. Vérifie les opérandes tant que leurs valeurs sont valides et sache quel type est utilisé pour chaque opération.

Limites des types signés et non signés

Le débordement d’entier signé est indéfini. Avec un int sur 32 bits, INT_MAX vaut 2 147 483 647 ; ajouter un n’est pas une méthode portable pour obtenir un nombre négatif. INT_MIN / -1, -INT_MIN et une multiplication trop grande échouent aussi lorsque le résultat mathématique n’est pas représentable.

L’arithmétique non signée reboucle dans la plage de son type. Pour un unsigned int sur 32 bits, UINT_MAX + 1u vaut zéro et 0u - 1u vaut 4 294 967 295. Ce comportement est défini mais peut quand même fausser un calcul de taille. Une boucle décroissante non signée utilisant i >= 0 n’atteint jamais une valeur d’arrêt négative.

Pour une addition générale d’entiers signés, vérifie avant d’additionner :

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

Les soustractions utilisées dans ces tests restent dans la plage autorisée car chacune est protégée par le test du signe de b. Calculer d’abord la somme puis la comparer est trop tardif. Un type plus large n’aide que s’il peut contenir tous les résultats intermédiaires : convertis un opérande avant l’opération. C23 fournit ckd_add dans <stdckdint.h> ; GCC et Clang proposent __builtin_add_overflow.

Division, décalages et conversions

Rejette zéro avant une division entière ou un calcul de reste. Rejette aussi la division du minimum d’un type signé par moins un lorsque son résultat n’est pas représentable. Les systèmes à virgule flottante IEEE 754 produisent couramment l’infini ou NaN lors d’une division par zéro, ce qui permet à des résultats numériques invalides de se propager sans interruption comparable à celle des entiers.

Pour les opérations sur les bits, utilise des opérandes non signés. Le nombre de positions du décalage doit être positif ou nul et inférieur à la largeur de l’opérande gauche après promotion. Avec des opérandes sur 32 bits, un décalage de 32 positions est indéfini. En C17, décaler vers la gauche une valeur signée négative est indéfini ; 1 << 31 est également indéfini pour un int sur 32 bits, tandis que 1u << 31 est valide pour un unsigned int sur 32 bits.

Une conversion d’une valeur à virgule flottante en entier exige que la valeur tronquée soit représentable, même si le type de destination est non signé. (unsigned)-1.0 est indéfini. La conversion d’un entier vers un type non signé ramène en revanche la valeur dans la plage de destination : (unsigned)-1 devient UINT_MAX. En C17, la conversion d’un entier hors plage vers un type signé est définie par l’implémentation. Vérifie les plages avant une conversion rétrécissante ; -Wconversion aide à révéler les changements implicites.

Rendre l’ordre d’évaluation sans conséquence

printf("%d %d\n", i, ++i); lit et modifie i sans l’ordre requis. i = i++ + 1; et a[i] = i++; contiennent aussi des opérations non séquencées. Sépare le travail en instructions distinctes, dans l’ordre voulu et explicite.

Initialise les variables automatiques avant de les lire : int sum = 0; donne un sens à sum += x;. Les variables globales et statiques sont initialisées à zéro. L’exigence de représentation en complément à deux de C23 ne définit pas le débordement d’entier signé ; le code portable a toujours besoin de vérifications.

Une adresse plausible ne suffit pas pour qu’un pointeur soit valide. L’objet doit exister, l’accès doit rester dans ses bornes et l’opération doit être autorisée pour cet objet. Ces vérifications expliquent aussi bien les plantages immédiats que les corruptions découvertes bien plus tard.

Rester dans les limites de l’objet

Un tableau de n éléments possède des indices de zéro à n - 1. Un pointeur juste après le dernier élément peut marquer la fin d’une boucle, mais tu ne dois pas le déréférencer. i <= n parcourt un élément de trop. La règle CERT ARR30-C couvre ces erreurs de limites.

Une écriture hors limites peut atteindre de la mémoire accessible appartenant à un autre objet. Le programme peut continuer jusqu’à ce qu’un nombre, un pointeur ou une donnée de l’allocateur endommagé soit utilisé. Un plantage ultérieur dans free n’indique pas l’écriture initiale. ASan peut s’arrêter sur l’écriture lorsque ses vérifications détectent le franchissement des limites.

Former une chaîne valide avec des caractères

Une chaîne C se termine par '\0'. Son stockage doit contenir un octet de plus que son nombre de caractères. C accepte char s[5] = "hello";, mais les cinq octets contiennent des lettres, sans place pour le caractère nul de fin. La passer à strlen ou à %s peut entraîner une lecture au-delà du tableau. Prévois assez de place et assure-toi qu’un caractère nul de fin est effectivement présent. STR31-C concerne la capacité ; STR32-C concerne le passage d’une chaîne terminée par un caractère nul.

Un littéral de chaîne de caractères n’est pas modifiable. Après char *p = "hi";, p[0] = 'H'; est indéfini. Utilise char p[] = "hi"; pour obtenir une copie modifiable, ou const char *p pour rendre les tentatives de modification du littéral visibles au compilateur. C’est l’objet de STR30-C.

Respecter la durée de vie et la propriété

Vérifie NULL avant de déréférencer le résultat d’une allocation, d’une ouverture de fichier ou d’une recherche. Lorsqu’un bloc est libéré, aucun pointeur vers ce bloc ne donne plus accès à un objet vivant. Ne lis pas ce bloc, n’y écris pas et ne le libère pas à nouveau. Libère uniquement le pointeur approprié renvoyé par une allocation dynamique, jamais un tableau local ou un pointeur intérieur. free(NULL) est sans danger, mais affecter la valeur nulle à un pointeur après la libération ne corrige pas les autres alias.

Une fonction qui renvoie l’adresse d’un tableau local renvoie un pointeur pendant :

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

La durée de vie du tableau prend fin au retour de la fonction. Fournis à la fonction appelante un tampon et sa capacité à remplir, ou alloue un résultat dont la propriété est transmise à la fonction appelante. Un affichage réussi immédiatement après le retour ne peut pas prolonger la durée de vie de l’ancien tableau.

Allouer les octets nécessaires à chaque élément

malloc(n) demande des octets, pas n objets du type pointé. L’expression habituelle fondée sur les éléments est n * sizeof *a. Empêche d’abord le rebouclage de ce produit :

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

Inclus <stdint.h> pour SIZE_MAX et <stdlib.h> pour les fonctions d’allocation. Une fois la taille validée, alloue la mémoire, vérifie le pointeur renvoyé et écris chaque valeur avant de la lire. malloc laisse la mémoire non initialisée. calloc(n, sizeof *a) met sa zone mémoire à zéro et les bibliothèques courantes rejettent les produits qui débordent. Une vérification de taille, une vérification du résultat de l’allocation et un indice valide résolvent des problèmes différents ; les trois comptent.

Une assertion exprime une propriété qui devrait être vraie si ton code est correct. Elle transforme une hypothèse fausse mais cachée en un arrêt proche de l’endroit où cette hypothèse compte.

Vérifier un contrat de programmation

Inclus <assert.h> et écris assert(condition);. Une condition vraie laisse l’exécution se poursuivre. Une condition fausse affiche des informations de diagnostic sur stderr et appelle abort(). Le message indique l’expression, son emplacement dans le code source et la fonction ; sa formulation exacte dépend de la plateforme.

Pour une fonction auxiliaire interne de calcul de moyenne dont la fonction appelante garantit la validité des arguments :

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

Un appel accidentel avec zéro élément échoue à l’endroit où la garantie est rompue. Sous un débogueur, bt montre le mécanisme de l’assertion et de l’arrêt, suivi des appels dans ton code. Sélectionne le cadre de la fonction appelante pour voir comment elle a fourni zéro.

Les contrats interviennent à plusieurs endroits :

Une assertion est une documentation exécutable : elle nomme la propriété et la vérifie pendant une exécution de test. Choisis des expressions qui observent l’état sans le modifier.

Garder les opérations nécessaires hors des assertions

Définir NDEBUG avant d’inclure <assert.h>, généralement avec -DNDEBUG, désactive assert. Son expression n’est pas évaluée. Cela crée un bogue grave si l’expression effectue une opération nécessaire :

assert(++count <= MAX);

L’incrémentation disparaît dans une version compilée avec NDEBUG. Écris l’action séparément :

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

La même règle exclut l’ouverture de fichiers, l’allocation de mémoire ou la fermeture de fichiers dans une assertion. Ces opérations doivent avoir lieu dans toutes les configurations. Leurs échecs nécessitent une gestion ordinaire des erreurs.

Gérer normalement les échecs prévisibles

Un fichier d’entrée absent, un texte utilisateur invalide et un épuisement de la mémoire peuvent survenir lors d’une utilisation correcte du programme. Vérifie ces situations avec if, signale l’erreur et effectue un retour ou libère les ressources. Une fonction auxiliaire privée peut vérifier par assertion qu’une valeur validée est dans une plage donnée, mais le point d’entrée public des données doit imposer cette plage avec des vérifications qui restent dans les versions de production.

Par exemple, teste toujours fclose(f) == EOF dans le déroulement ordinaire du programme lors de la fermeture d’un fichier de sortie. L’écriture des données en tampon peut échouer pendant la fermeture ; supprimer l’appel ou sa vérification peut masquer une perte de données.

Vérifier les faits fixes à la compilation

Une assertion statique teste une expression constante pendant la compilation. En C17, <assert.h> fournit static_assert comme macro pour _Static_assert de C11 :

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

Une condition fausse fait échouer la compilation. Elle ne peut pas vérifier un nombre saisi par l’utilisateur qui n’est connu qu’à l’exécution. C23 fait de static_assert un mot-clé et permet d’omettre le message. Utilise cette distinction pour placer chaque vérification là où les informations nécessaires sont disponibles.

AddressSanitizer, généralement appelé ASan, ajoute des vérifications aux opérations mémoire compilées. Il peut signaler un accès incorrect au moment où il se produit, avant que les données corrompues ne provoquent un plantage ailleurs.

Compiler en incluant les vérifications à l’édition de liens

Utilise GCC ou Clang pour compiler et effectuer l’édition de liens avec ASan :

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

-g fournit les emplacements dans le code source. La conservation des pointeurs de cadre facilite les traces de pile. Pour un projet composé de plusieurs fichiers, instrumente les fichiers source concernés et utilise aussi l’option du sanitizer à l’étape finale d’édition de liens. MSVC fournit /fsanitize=address pour les compilations Windows prises en charge.

ASan détecte de nombreux débordements de blocs du tas, de tableaux de la pile et de tableaux globaux. Il détecte aussi les utilisations après libération, les doubles libérations, les libérations invalides et les erreurs prises en charge liées à l’utilisation après la fin d’une portée. Sous Linux, l’environnement d’exécution ASan habituel comprend la recherche de fuites à la fin du programme. Le Clang fourni par Apple sous macOS ne propose pas cette détection des fuites ; les chaînes d’outils LLVM et la prise en charge varient selon la plateforme.

Remonter d’un rapport à la cause

Considère un tableau dont l’allocation a réussi, avec des int de 4 octets :

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

L’allocation contient 40 octets. Les indices de zéro à neuf utilisent ces octets. L’indice dix commence immédiatement après. ASan peut signaler « heap-buffer-overflow », « WRITE of size 4 » et un emplacement situé zéro octet après une zone de 40 octets. La trace de l’écriture indique l’affectation ; la trace de l’allocation indique le malloc qui a établi les limites du bloc.

Lis les rapports dans cet ordre :

1. Identifie la catégorie d’erreur et détermine si l’accès était une lecture ou une écriture.
2. Trouve le premier cadre situé dans ton code dans la trace de l’accès.
3. Compare l’accès à la zone allouée et à la taille de ses éléments.
4. Pour une erreur de durée de vie, trouve aussi les traces d’allocation et de libération.

Ici, la correction est i < 10. Allouer un élément supplémentaire tout en conservant la mauvaise condition d’arrêt masque l’incompatibilité entre le nombre d’éléments prévu et la boucle. ASan s’arrête par défaut à la première erreur détectée. Corrige-la, recompile et relance le programme.

Comprendre les limites de l’outil

ASan suit les accès mémoire autorisés à l’aide d’une mémoire fantôme. Des zones rouges interdites entourent les allocations et les tableaux pris en charge. Les blocs libérés passent un certain temps en quarantaine avant leur réutilisation, ce qui aide à révéler les accès à de la mémoire libérée. Une écriture au-delà d’un membre tableau jusque dans un autre membre de la même structure peut rester dans une zone valide plus grande et échapper à la détection.

ASan ne vérifie pas les lectures ordinaires de valeurs non initialisées. Memcheck de Valgrind peut trouver ces utilisations et de nombreux défauts du tas sans recompilation, mais s’exécute couramment environ 20 à 30 fois plus lentement. Le ralentissement typique d’ASan est d’environ deux fois, avec une utilisation supplémentaire de mémoire. Ne combine pas une version compilée avec ASan avec Valgrind, MemorySanitizer ou ThreadSanitizer. Exécute délibérément des entrées correspondant aux cas limites : une erreur sur un chemin non exécuté ne peut pas apparaître dans le rapport.

Un outil de vérification de la mémoire ne couvre pas toutes les opérations C invalides. UndefinedBehaviorSanitizer, ou UBSan, instrumente de nombreuses opérations arithmétiques, sur les pointeurs et sur les tableaux. Associe-le à ASan pour qu’une exécution de test puisse détecter plusieurs catégories de défauts.

Rendre les erreurs de calcul visibles

Avec un int sur 32 bits, l’addition de deux valeurs de 2 000 000 000 donne un total de 4 000 000 000. Ce résultat dépasse INT_MAX. Un rapport UBSan indique le débordement d’entier signé à l’addition et nomme les opérandes. Sans l’outil, l’affichage d’une réponse négative ressemblant à une valeur rebouclée ne rendrait pas l’opération valide.

Utilise pour le total un type capable de représenter la plage acceptée, ou rejette une addition avant qu’elle ne déborde. Convertir en long long un résultat qui a déjà débordé est trop tardif ; l’opération elle-même doit utiliser un type adapté.

Une commande de test courante est :

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

UBSan permet normalement de poursuivre après de nombreux signalements, si bien que le code ultérieur peut continuer. -fno-sanitize-recover=undefined fait arrêter le test avec un code de retour d’erreur lors de ces échecs. Cela aide les vérifications automatisées à détecter un bogue même lorsque la sortie finale affichée semble correcte.

Choisir l’outil adapté au défaut

Le rebouclage des entiers non signés est défini, donc le groupe undefined ne le signale pas. Clang dispose d’une vérification distincte, -fsanitize=unsigned-integer-overflow, pour le code où un rebouclage indique un bogue. Ne conclus pas que tout résultat entier indésirable est un comportement indéfini.

MemorySanitizer est un outil Clang utilisé principalement sous Linux ; des bibliothèques non instrumentées peuvent perturber son suivi. ThreadSanitizer détecte les accès conflictuels de threads sans synchronisation, avec au moins une écriture. Les accès ne doivent pas nécessairement avoir lieu exactement au même instant. Aucun de ces outils ne peut être combiné à ASan dans une même version compilée.

Faire des vérifications une habitude

Garde les avertissements activés et résous-les. Compile avec ASan et UBSan, puis exécute le programme avec des entrées vides, des entrées à un élément, des tampons pleins, du texte invalide et des valeurs proches des bornes acceptées. Lance une analyse statique pour examiner les chemins que les tests peuvent manquer et répète automatiquement les vérifications lorsque le code change. Exécute aussi la configuration de production, dont les paramètres d’optimisation et d’assertion diffèrent.

Le fuzzing fournit de nombreuses entrées générées ou modifiées. libFuzzer et AFL++ peuvent révéler des chemins inhabituels dans un analyseur ; les sanitizers transforment une opération invalide déclenchée en un rapport utile. Sauvegarde une entrée qui révèle un défaut, réduis-la sans perdre la défaillance, corrige la cause et conserve-la comme test de non-régression. Une exécution sans erreur constitue un indice concernant les entrées exécutées, pas une garantie pour toutes les exécutions possibles.

Un référentiel de programmation sécurisée rassemble des règles concrètes qui préviennent les défauts récurrents. Il fournit à la personne qui relit le code des questions plus utiles que « Cela semble-t-il sûr ? ». Chaque règle relie une opération risquée à la condition ou à la conception nécessaire pour la rendre sûre.

Lire une règle pour en comprendre la raison

Le SEI CERT C Coding Standard provient du Software Engineering Institute de Carnegie Mellon University. L’édition imprimée de 2016 est accompagnée d’une version en ligne qui évolue. Il distingue les règles, dont la violation risque de causer des défauts, des recommandations qui améliorent la fiabilité et la sécurité.

Les identifiants combinent une catégorie, un nombre et -C. Les règles utilisent les nombres de 30 à 99 ; les recommandations, de 00 à 29. Par exemple, INT32-C concerne le débordement d’entier signé, tandis que DCL00-C est une recommandation sur les déclarations. Les catégories comprennent les déclarations (DCL), les expressions (EXP), les entiers (INT), la virgule flottante (FLP), les tableaux (ARR), les chaînes (STR), la mémoire (MEM), les entrées-sorties (FIO), l’environnement (ENV), les erreurs (ERR) et divers sujets (MSC).

La page d’une règle explique normalement le défaut, montre du code non conforme, présente des solutions conformes et évalue le risque. Lis les hypothèses de chaque solution. Une fonction de remplacement n’est utile que si son comportement répond effectivement à l’exigence.

Appliquer une règle au parcours des données

FIO30-C concerne les chaînes de format. Ce code traite des données extérieures comme un programme de mise en forme :

printf(user_name);

Un nom d’utilisateur contenant des conversions de format amène printf à chercher des arguments qui n’ont pas été fournis ; %n peut provoquer une écriture en mémoire. Garde le format sous le contrôle du programme :

printf("%s", user_name);

Autre possibilité : fputs(user_name, stdout) affiche le texte sans traitement de format. -Wformat=2 comprend des vérifications qui aident à trouver les formats non sûrs. La correction change la façon dont les données sont interprétées, pas simplement la longueur possible de la chaîne.

Construire une liste de vérification utile

Pour la mémoire, demande-toi si les indices restent dans les objets (ARR30-C), si le stockage des chaînes comprend le caractère nul de fin (STR31-C), si la mémoire libérée n’est jamais utilisée (MEM30-C), si les allocations dont le code est responsable sont libérées (MEM31-C), si seules les allocations valides sont libérées (MEM34-C) et si assez d’octets sont alloués (MEM35-C).

Pour les expressions, vérifie les rebouclages non voulus d’entiers non signés (INT30-C), les débordements d’entiers signés (INT32-C), les divisions invalides (INT33-C), les lectures de valeurs non initialisées (EXP33-C) et les déréférencements de pointeurs nuls (EXP34-C). Aux points d’utilisation des bibliothèques, gère les échecs signalés (ERR33-C) et les erreurs de conversion (ERR34-C). Évite system() comme le prescrit ENV33-C, car un interpréteur de commandes interprète son entrée.

Les tableaux de risque notent la gravité, la probabilité et le coût de correction de 1 à 3 ; une note de coût plus élevée signifie une correction moins coûteuse. Leur produit donne la priorité, de 1 à 27. Les niveaux regroupent les priorités en L1 (12–27), L2 (6–9) et L3 (1–4). Cela aide à ordonner les corrections sans déclarer inoffensifs les défauts de priorité inférieure.

Utilise les règles pendant la revue de code et exploite les résultats des analyseurs associés à leurs identifiants. MISRA C est un autre référentiel utilisé pour les logiciels embarqués critiques pour la sécurité. Les règles aident à prévenir les défauts, tandis que les avertissements, les tests et les sanitizers vérifient si l’implémentation les respecte effectivement. Mémoriser les identifiants ne suffit pas à détecter un caractère nul de fin manquant ou une branche de gestion d’erreur ignorée.

Pour manipuler les chaînes en toute sécurité, il faut une source valide, une capacité de destination connue et une décision sur le texte qui ne tient pas. Une fonction limitée par la taille empêche certains écrasements, mais tu dois quand même vérifier si toute l’opération a réussi.

Transmettre la capacité avec le pointeur

sizeof mesure le type de son opérande. Pour un tableau local char buf[20], il donne 20 octets. Dans void fill(char buf[]), le paramètre est ajusté en pointeur ; sizeof buf mesure ce pointeur, pas le tableau de la fonction appelante. Passe un paramètre de capacité, par exemple avec fill(buf, sizeof buf), tant que la fonction appelante dispose encore du type tableau.

Une chaîne de cinq caractères nécessite six octets en comptant '\0'. La capacité compte chaque octet accessible en écriture ; la longueur de la chaîne exclut le caractère nul de fin. C’est pourquoi malloc(strlen(src)) alloue un octet de trop peu pour une copie.

Lire une ligne dans les limites du tampon

Utilise fgets(buf, sizeof buf, stdin) et vérifie sa valeur de retour avant d’utiliser le contenu. La fonction stocke au plus un caractère de moins que la capacité, puis un caractère nul de fin. Elle conserve le saut de ligne si celui-ci tient dans le tampon. Après une lecture réussie, buf[strcspn(buf, "\n")] = '\0'; supprime un saut de ligne stocké.

Si une ligne longue remplit le tampon, les caractères non lus restent pour l’appel suivant. Décide si tu dois rejeter l’entrée et lire le reste pour l’évacuer, poursuivre la lecture ou accepter la troncature. Supprimer un saut de ligne ne prouve pas que tu as lu la ligne entière. gets ne permet pas d’indiquer une capacité et a été retiré en C11 ; ne l’utilise jamais.

Pour un seul mot dans char name[20], %19s dans scanf limite les caractères stockés et laisse de la place pour le caractère nul de fin. Vérifie que le nombre attendu de conversions a réussi. Pour du texte numérique non fiable, préfère une ligne complète suivie d’un strtol dont le résultat est vérifié ; %d a un comportement indéfini lorsque la valeur convertie n’est pas représentable, même si tu inspectes le nombre renvoyé par scanf.

Détecter une copie raccourcie

strcpy et strcat ne connaissent pas la capacité de la destination. strncpy peut laisser le résultat sans caractère nul de fin. Avec une capacité positive, snprintf termine le texte stocké par un caractère nul et indique le nombre de caractères nécessaires à la sortie complète :

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

La chaîne stockée est « debuggi » et r vaut 9. La sortie complète nécessite dix octets en comptant son caractère nul de fin. Vérifie que le résultat n’est pas négatif avant de le convertir en size_t. Pour que le résultat tienne, r doit être inférieur à la capacité.

Adapter l’opération à la zone mémoire

Utilise memmove lorsque la source et la destination se chevauchent ; memcpy avec des zones qui se chevauchent est indéfini. strlcpy est disponible sur les systèmes BSD, macOS et glibc à partir de la version 2.38, mais ne fait pas partie d’ISO C. Les fonctions de l’annexe K sont facultatives et absentes de nombreuses bibliothèques.

Ne place pas de données utilisateur dans le format lui-même. Fais correspondre chaque conversion à son argument : %d pour int, %ld pour long, %zu pour size_t, %f pour double et %s pour une chaîne terminée par un caractère nul. %p exige un void * : passe donc une conversion appropriée du pointeur. Une limite de largeur ne peut pas corriger un type d’argument incompatible.

Des données extérieures peuvent être syntaxiquement valides et rester dangereuses pour l’opération envisagée. Valide leur longueur, leur format complet et leur plage de valeurs utile avant de les utiliser comme indice, taille d’allocation ou nombre d’itérations.

Analyser le nombre entier

atoi ne fournit aucun moyen fiable de distinguer un zéro valide d’un texte invalide, et un résultat non représentable entraîne un comportement indéfini. strtol fournit un pointeur de fin de conversion et signale les erreurs de plage. Après avoir lu une ligne complète et supprimé son saut de ligne, un analyseur décimal strict peut utiliser :

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

Inclus <errno.h> et <stdlib.h>. Le premier test distingue trois échecs : absence de chiffres, texte final et valeur hors de la plage de long. Le test de la plage autorisée par l’application intervient avant la conversion rétrécissante vers int. strtol accepte les espaces initiaux et un signe facultatif ; décide si la grammaire de l’application les autorise.

Pour « 42abc », la conversion peut renvoyer 42, mais end pointe vers les lettres restantes. Pour « abc », aucun chiffre n’est consommé. Pour un entier décimal trop grand, errno prend la valeur ERANGE. Un nombre non nul renvoyé ne prouve à lui seul ni que la conversion est complète ni que la valeur est dans une plage sûre.

Préserver la propriété en cas d’échec

Chaque opération susceptible d’échouer nécessite une réponse. Vérifie les résultats des allocations, de fopen et de fgets, le nombre d’affectations réussies et l’achèvement des sorties. Un retour NULL de fgets peut indiquer une fin d’entrée ou une erreur de lecture. fclose peut signaler l’échec d’une écriture en tampon. Utilise les informations d’erreur adaptées à la fonction ; de nombreux appels de bibliothèque définissent errno, que perror ou strerror peut transformer en diagnostic lisible.

Pour un redimensionnement vers une taille positive, protège le calcul de taille et l’allocation initiale :

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

Affecter le résultat de realloc directement au seul pointeur responsable de l’allocation fait perdre l’adresse de l’ancien bloc en cas d’échec. Traite zéro séparément : en C17, le comportement de realloc avec une taille nulle est défini par l’implémentation, tandis qu’en C23 il est indéfini. Après un redimensionnement réussi, utilise le pointeur renvoyé et abandonne les alias devenus invalides.

Prévoir un chemin de gestion d’erreur clair

Une section unique de nettoyage peut libérer les ressources acquises dans l’ordre inverse. Initialise à NULL les pointeurs responsables d’une allocation, ne ferme que les fichiers ouverts et renvoie un code d’échec après avoir signalé la cause. Un goto cleanup peut rendre ces chemins plus faciles à examiner.

Évite system() pour les tâches impliquant du texte extérieur : l’interpréteur de commandes peut interpréter ce texte comme des commandes. Préfère une opération de bibliothèque ou une interface adaptée au lancement d’un programme avec des arguments transmis séparément. Considère les arguments de ligne de commande, les valeurs d’environnement, le contenu des fichiers et les données réseau comme des entrées qui exigent autant de précautions que le texte saisi.

La sécurité mémoire signifie que les accès restent dans les zones mémoire qu’un programme est autorisé à utiliser. C donne un contrôle direct de la mémoire et laisse au programmeur les vérifications des bornes et des durées de vie.

Distinguer les bornes de la durée de vie

La sécurité spatiale maintient un accès dans les bornes de son objet. Écrire l’élément d’indice dix d’un tableau de dix éléments la viole. La sécurité temporelle maintient l’accès dans la durée de vie de l’objet. Lire une allocation après free, la libérer deux fois ou utiliser l’adresse renvoyée d’une variable locale viole les règles de durée de vie.

Les conséquences peuvent aller au-delà d’un plantage. Une lecture peut exposer des données confidentielles. Une écriture peut corrompre un fichier, modifier des données de contrôle ou créer une vulnérabilité de sécurité lorsque des données extérieures contrôlent l’opération. Un programme qui continue après une corruption peut produire des résultats convaincants mais faux.

Cette responsabilité concerne aussi les équipes expérimentées. Microsoft a indiqué en 2019 que, chaque année pendant plus d’une décennie, environ 70 % des vulnérabilités auxquelles l’entreprise avait attribué un identifiant CVE concernaient la sécurité mémoire. En décembre 2023, la CISA et des agences partenaires ont appelé les éditeurs de logiciels à prévoir des transitions vers des langages à sécurité mémoire. Ce sont des observations historiques précises, pas un pourcentage mesuré pour chaque programme C.

Comprendre les raisons de choisir C

C offre un contrôle de la disposition et de l’allocation de la mémoire ainsi que de l’accès au matériel, sans imposer de ramasse-miettes. Son environnement d’exécution réduit convient aux micrologiciels soumis à de fortes contraintes. Il bénéficie d’une large prise en charge par les compilateurs, d’importants ensembles de code existant et d’interfaces que de nombreux autres langages peuvent appeler. Ces avantages expliquent son utilisation dans les noyaux de systèmes d’exploitation, les logiciels embarqués, les environnements d’exécution et les bibliothèques.

Ils ne rendent pas tous les programmes C rapides de façon prévisible : les algorithmes, les allocations, les caches et les appels système comptent toujours. L’avantage pertinent est le contrôle des coûts et des besoins de l’environnement d’exécution.

Les opérations non sûres et les interfaces avec C exigent une attention particulière dans les systèmes par ailleurs à sécurité mémoire. La sécurité mémoire laisse aussi à résoudre les erreurs de logique et les injections liées aux données d’entrée.

Choisir plusieurs niveaux de protection pour le risque restant

Préviens les défauts avec des règles de programmation, des avertissements et des revues de code. Détecte-les avec l’analyse statique, les tests aux limites, les sanitizers et le fuzzing. Limite les dommages restants avec des protections de pile, les vérifications _FORTIFY_SOURCE prises en charge, la randomisation de l’espace d’adressage (ASLR) et la mémoire non exécutable. Une mesure d’atténuation peut arrêter une attaque ou transformer une corruption en plantage tout en laissant le défaut dans le code source.

Les coûts guident le déploiement. ASan double généralement le temps d’exécution et augmente l’utilisation de mémoire ; Valgrind ralentit couramment l’exécution de 20 à 30 fois. Ils conviennent davantage aux tests qu’à une utilisation ordinaire en production. Le durcissement moins coûteux reste couramment actif dans les versions de production.

Pour un nouvel analyseur de fichiers provenant d’Internet, sans contrainte imposant C, un langage à sécurité mémoire réduit un risque majeur. Pour un micrologiciel C existant sur un microcontrôleur doté de 32 Ko de mémoire, la prise en charge du langage et les limites de ressources peuvent favoriser C avec des vérifications rigoureuses. Fonde ton choix sur les contraintes, l’exposition aux données d’entrée et la facilité de maintenance ; le remplacement progressif d’un analyseur risqué peut aussi être une solution pratique.