Chapitre 1 · 4 h
Tableaux
Déclaration, indices et parcours, tableaux à deux dimensions, tableau passé en paramètre, et l'absence totale de vérification des bornes en C.
int T[5];T[10] = 42;Ce programme compile sans avertissement et s'exécute sans erreur. Il écrit 42 vingt octets plus loin que la fin du tableau, sur ce qui s'y trouvait — une autre variable, l'adresse de retour de la fonction, n'importe quoi. Le programme continue, avec un état corrompu, et plantera peut-être mille lignes plus loin.
Le C ne vérifie jamais les bornes d'un tableau. Ce n'est pas un oubli de la norme, c'est une décision : vérifier coûterait une comparaison à chaque accès, et le C a été conçu pour écrire des systèmes d'exploitation. Le prix est une classe entière de vulnérabilités, et une bonne partie du chapitre 10.
Déclarer et parcourir
int notes[5] = {12, 15, 8, 17, 10};int vide[100] = {0}; /* toutes les cases à zéro */int deduit[] = {1, 2, 3}; /* taille déduite : 3 */Trois faits à poser fermement.
Les indices vont de 0 à n−1. notes[0] est le premier, notes[4] le dernier, notes[5]
n'existe pas. L'idiome for (int i = 0; i < n; i++) du chapitre 3 donne exactement les indices
valides, et c'est la raison de l'employer systématiquement.
Les éléments sont contigus. Un int T[5] occupe vingt octets consécutifs, et l'adresse de
T[i] vaut celle de T[0] plus . C'est l'accès en d'Algorithmique 1, et
c'est aussi la localité spatiale du chapitre 7 d'architecture — parcourir un tableau dans
l'ordre est ce qu'une machine fait le plus vite.
La taille est fixée à la compilation et ne peut pas changer. Un tableau dont la taille dépend de l'exécution demande l'allocation dynamique du chapitre 8.
Enfin, {0} initialise toutes les cases à zéro, alors qu'un tableau non initialisé contient
n'importe quoi — même règle qu'au chapitre 2 pour les variables.
L'absence de vérification
Voici ce qui se passe réellement lors d'un débordement, et pourquoi c'est pire qu'une erreur.
L'expression T[i] est traduite en une adresse : début du tableau plus fois la taille
d'un élément. Le compilateur émet ce calcul sans se demander si est valide — il ne le sait
pas toujours, et le vérifier coûterait un test à chaque accès.
pile (adresses croissantes)┌──────────┬──────────┬──────────┬──────────┬──────────┬───────────┐│ T[0] │ T[1] │ T[2] │ T[3] │ T[4] │ secret │└──────────┴──────────┴──────────┴──────────┴──────────┴───────────┘ ▲ T[5] écrit ICITrois issues possibles, et la troisième est la plus dangereuse. L'adresse touchée peut être dans une page interdite : erreur de segmentation, le programme meurt, et c'est le meilleur cas — l'erreur est immédiate. Elle peut appartenir à une autre variable : corruption silencieuse, le programme continue avec des données fausses. Elle peut enfin être l'adresse de retour de la fonction, et un attaquant qui contrôle ce qui est écrit contrôle alors où le programme va sauter : c'est le débordement de tampon, sujet du chapitre 8 de cybersécurité.
La règle pratique est donc : la taille voyage avec le tableau. Toute fonction qui reçoit un tableau reçoit aussi son nombre d'éléments, et vérifie ses indices elle-même. Le langage ne le fera pas.
Tableaux à deux dimensions
int grille[3][4]; /* 3 lignes de 4 colonnes */grille[1][2] = 7;La mémoire reste linéaire : le tableau est rangé ligne par ligne, et l'adresse de
grille[i][j] se calcule comme
Ce détail a une conséquence mesurable, celle de l'exercice du chapitre 7 d'architecture : parcourir par lignes suit l'ordre mémoire et exploite le cache ; parcourir par colonnes saute d'une ligne à l'autre à chaque accès et peut être plusieurs fois plus lent, pour exactement le même nombre d'opérations.
Un tableau en paramètre n'est pas copié
C'est l'exception à la règle du chapitre 4, et elle est majeure.
void modifier(int T[], int n) { T[0] = 99; /* modifie le tableau de l'APPELANT */}Un paramètre déclaré int T[] est en réalité un int * : ce qui est copié n'est pas le
tableau mais l'adresse de son premier élément. La fonction travaille donc sur l'original.
Ce n'est pas une entorse au passage par valeur — l'adresse, elle, est bien copiée — mais une conséquence de la conversion tableau-pointeur que le chapitre 7 expliquera. Deux conséquences immédiates.
Passer un grand tableau ne coûte rien : huit octets, quelle que soit sa taille. C'est
efficace, et c'est aussi pourquoi le C n'offre aucun moyen simple de passer un tableau en
lecture seule — on écrit const int T[] pour l'exprimer.
sizeof ne fonctionne plus. Dans la fonction, sizeof(T) rend la taille d'un pointeur —
8 — et non celle du tableau. L'astuce sizeof(T)/sizeof(T[0]) fonctionne uniquement là où le
tableau a été déclaré, et devient silencieusement fausse dans toute fonction. C'est
précisément pourquoi il faut passer la taille en second paramètre.
Quiz · 1 question
Une fonction reçoit int T[] et calcule sizeof(T)/sizeof(T[0]) pour connaître le nombre d'éléments. Que vaut ce calcul ?
- Le nombre d'éléments du tableau : c'est l'idiome standard — le bon nombre
- 8 divisé par 4, soit 2, quelle que soit la taille réelle : le paramètre est un POINTEUR, et sizeof rend la taille du pointeur — d'où l'obligation de passer la taille en paramètre — toujours 2
- Une erreur de compilation, car sizeof ne s'applique pas aux paramètres — erreur
Réponse : L'idiome sizeof(T)/sizeof(T[0]) fonctionne, mais UNIQUEMENT dans la portée où le tableau a été déclaré — là où le compilateur connaît sa taille. Dès qu'un tableau est passé en paramètre, il se convertit en pointeur sur son premier élément : le paramètre int T[] est strictement équivalent à int *T, et sizeof(T) rend 8, la taille d'un pointeur sur une machine 64 bits. Sur des int de 4 octets, le calcul donne donc invariablement 2. Le plus dangereux est que ce code compile sans avertissement (gcc -Wall en émet un, encore une raison de l'activer) et qu'il donne un résultat plausible : un tableau de deux éléments existe. D'où la règle : LA TAILLE VOYAGE AVEC LE TABLEAU, en second paramètre.
Quiz · 1 question
Pourquoi int T[5]; T[10] = 42; ne provoque-t-il ni erreur de compilation ni erreur d'exécution ?
- Parce que le compilateur agrandit automatiquement le tableau si nécessaire — agrandissement
- Parce que T[i] est traduit en un simple calcul d'adresse, sans aucun test : l'écriture atteint la mémoire voisine, qui appartient à autre chose — corruption silencieuse plutôt qu'erreur — calcul d'adresse sans test
- Parce que 42 tient dans un int, donc l'écriture est valide où qu'elle aille — taille de la valeur
Réponse : Le compilateur traduit T[i] en « adresse de T plus i fois la taille d'un élément », et émet ce calcul sans le vérifier — il ne connaît pas toujours i, et le tester coûterait une comparaison à chaque accès, ce que le C refuse de payer. L'écriture atteint donc les vingt octets suivants, qui appartiennent à autre chose. Trois issues : page interdite et erreur de segmentation, ce qui est le MEILLEUR cas puisque l'erreur est immédiate ; autre variable écrasée, donc corruption silencieuse et plantage à retardement ; ou adresse de retour de la fonction, auquel cas un attaquant qui contrôle la donnée écrite contrôle où le programme saute. C'est le débordement de tampon, et c'est pourquoi valgrind existe.
À vous
L'exercice modélise un cadre de pile — un tableau et ses variables voisines dans une même zone mémoire — puis vous fait écrire hors bornes pour observer ce qui est écrasé.
Vous verrez les trois issues : la corruption d'une variable voisine, l'écrasement d'une valeur sensible, et l'accès à une adresse interdite. Vous écrirez ensuite la version défensive, où la fonction reçoit la taille et vérifie ses indices — la seule protection dont on dispose en C.
La dernière partie mesure le parcours d'une matrice par lignes et par colonnes, comme au chapitre 7 d'architecture, mais cette fois sur la représentation linéaire du C : c'est le même tableau, et le calcul d'adresse rend l'écart évident.
Exercice de code
Écrivez hors bornes et observez ce qui est écrasé, puis écrivez la version défensive.
Point de départ
// ── Un cadre de pile, avec ses variables voisines ─────────────────────────
// La zone est un tableau d'octets ; chaque variable occupe une plage.
function creerCadre() {
const OCTETS = 40;
const memoire = new Array(OCTETS).fill(0);
const PLAN = {
"T[0..4]": { debut: 0, taille: 20 }, // int T[5], 4 octets chacun
"secret": { debut: 20, taille: 4 },
"adresseRetour":{ debut: 24, taille: 4 },
};
const INTERDIT = 36; // au-delà : page non allouée
function nomDe(octet) {
for (const [nom, p] of Object.entries(PLAN)) {
if (octet >= p.debut && octet < p.debut + p.taille) return nom;
}
return "zone non allouée";
}
return {
plan: PLAN,
// Écrit un int de 4 octets à l'indice i du tableau T. AUCUN contrôle.
ecrireT(i, valeur) {
const octet = 0 + i * 4;
if (octet >= INTERDIT) return { erreur: "Segmentation fault (adresse " + octet + ")" };
memoire[octet] = valeur;
return { touche: nomDe(octet), octet };
},
lire(nom) {
const p = PLAN[nom];
return memoire[p.debut];
},
poser(nom, v) { memoire[PLAN[nom].debut] = v; },
};
}
// ── Version défensive ─────────────────────────────────────────────────────
// La seule protection en C : la taille voyage avec le tableau.
function ecrireSur(cadre, i, n, valeur) {
// ← à écrire : refuser si i est hors de [0, n[, sinon écrire
return cadre.ecrireT(i, valeur);
}
// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez T[5], T[6] et T[12]. Que touche chacun ?
// 2. Écrivez ecrireSur() et vérifiez qu'elle refuse proprement.
// 3. Comparez le parcours d'une matrice 4x4 par lignes et par colonnes :
// même nombre d'accès, quelle différence sur les adresses visitées ?
const c = creerCadre();
c.poser("secret", 1234);
c.poser("adresseRetour", 9999);
console.log("T[2] :", JSON.stringify(c.ecrireT(2, 42)));
Solution
function creerCadre() {
const OCTETS = 40;
const memoire = new Array(OCTETS).fill(0);
const PLAN = {
"T[0..4]": { debut: 0, taille: 20 },
"secret": { debut: 20, taille: 4 },
"adresseRetour": { debut: 24, taille: 4 },
};
const INTERDIT = 36;
function nomDe(octet) {
for (const [nom, p] of Object.entries(PLAN)) {
if (octet >= p.debut && octet < p.debut + p.taille) return nom;
}
return "zone non allouée";
}
return {
plan: PLAN,
ecrireT(i, valeur) {
const octet = i * 4;
if (octet >= INTERDIT) return { erreur: "Segmentation fault (adresse " + octet + ")" };
memoire[octet] = valeur;
return { touche: nomDe(octet), octet };
},
lire(nom) { return memoire[PLAN[nom].debut]; },
poser(nom, v) { memoire[PLAN[nom].debut] = v; },
};
}
function ecrireSur(cadre, i, n, valeur) {
// La seule protection dont on dispose en C : la vérifier soi-même, avec
// une taille qu'on s'est donné la peine de transmettre.
if (i < 0 || i >= n) return { erreur: "indice " + i + " hors de [0, " + n + "[" };
return cadre.ecrireT(i, valeur);
}
console.log("— écriture sans contrôle —");
const c = creerCadre();
c.poser("secret", 1234);
c.poser("adresseRetour", 9999);
for (const i of [2, 4, 5, 6, 12]) {
const r = c.ecrireT(i, 42);
const etiquette = "T[" + i + "]";
if (r.erreur) console.log(" " + etiquette.padEnd(7) + "-> " + r.erreur);
else console.log(" " + etiquette.padEnd(7) + "-> octet " + String(r.octet).padStart(2) +
", touche « " + r.touche + " »" +
(i >= 5 ? " << HORS BORNES, et aucune erreur" : ""));
}
console.log(" secret vaut maintenant " + c.lire("secret") +
" (il valait 1234) et adresseRetour " + c.lire("adresseRetour") + " (il valait 9999)");
// T[5] a écrasé une variable voisine : corruption silencieuse. T[6] a écrasé
// l'adresse de retour : c'est là qu'un attaquant prend la main. T[12] tombe
// dans une page interdite, et c'est le seul cas où le programme s'arrête —
// donc le plus favorable, contre toute intuition.
console.log("");
console.log("— version défensive —");
const d = creerCadre();
for (const i of [2, 5]) {
const r = ecrireSur(d, i, 5, 42);
console.log(" T[" + i + "] -> " + (r.erreur ?? "écrit dans « " + r.touche + " »"));
}
console.log("");
console.log("— matrice 4x4 : ordre des adresses visitées —");
const N = 4;
const adresse = (i, j) => (i * N + j) * 4;
const parLignes = [], parColonnes = [];
for (let i = 0; i < N; i++) for (let j = 0; j < N; j++) parLignes.push(adresse(i, j));
for (let j = 0; j < N; j++) for (let i = 0; i < N; i++) parColonnes.push(adresse(i, j));
console.log(" par lignes : " + parLignes.join(" "));
console.log(" par colonnes : " + parColonnes.join(" "));
const saut = (t) => t.slice(1).reduce((s, a, k) => s + Math.abs(a - t[k]), 0);
console.log(" distance totale parcourue : " + saut(parLignes) + " octets par lignes, " +
saut(parColonnes) + " par colonnes");
// Mêmes seize accès, mêmes seize adresses — mais dans un ordre qui saute.
// Le cache rapporte une ligne de 64 octets à chaque défaut : par lignes,
// elle sert quatre fois de suite ; par colonnes, une seule.
En travaux pratiques
Travaux pratiques 5 · 3 h
Sortir du tableau, exprès
Constater que le C ne vérifie aucun indice, mesurer ce que cela permet, et adopter les deux outils qui rendent l'erreur visible.
Avant de commencer
- Les TP 1 à 4
- gcc avec -fsanitize=address
Énoncé
- Écrire à côté — Déclarez un tableau de cinq entiers et écrivez à l'indice 5, 6, puis 100. Compilez avec -Wall et exécutez. Notez ce qui plante et ce qui ne plante pas.
- Écraser une variable choisie — Déclarez une variable juste après le tableau, affichez son adresse et celle du tableau, puis modifiez-la en écrivant hors du tableau. Vous venez de faire un débordement dirigé. Indice : La différence des adresses vous donne l'indice à viser.
- L'outil qui voit — Recompilez avec le détecteur d'adresses et relancez. Lisez le rapport : il donne le tableau, l'indice, et la ligne. Comparez à votre diagnostic sans outil.
- sizeof, et où il ment — Affichez la taille d'un tableau dans la fonction qui le déclare, puis dans une fonction à laquelle vous le passez. Expliquez l'écart.
- Tableau à deux dimensions — Créez une matrice, remplissez-la par lignes puis par colonnes, et chronométrez. Retrouvez le résultat du TP 7 d'Architecture, cette fois dans votre propre code.
- Au fil rouge — Ajoutez à journal un histogramme du nombre de lignes par heure, sur 24 cases. Faites-le d'abord sans contrôle d'indice, testez avec une heure invalide, puis protégez.
- La bonne façon de passer un tableau — Réécrivez toutes vos fonctions prenant un tableau pour qu'elles prennent aussi sa taille. Ajoutez const là où c'est possible, et vérifiez que le compilateur refuse une modification.
C'est réussi quand
- Vous provoquez un débordement qui ne plante PAS, et vous savez pourquoi c'est le cas dangereux
- Le détecteur d'adresses vous donne la ligne exacte que vous cherchiez à la main
- Toutes vos fonctions reçoivent la taille du tableau qu'elles parcourent
Correction
int t[5] = {0};
t[5] = 42; /* hors bornes : compile, s'exécute, NE PLANTE PAS */
t[6] = 42; /* idem */
t[100] = 42; /* peut-être hors de la pile → Segmentation fault */
gcc -Wall : aucun avertissement sur t[i] avec i variableLe C ne vérifie pas les indices, et c'est un CHOIX de conception : la vérification coûterait un test à chaque accès. Le cas dangereux n'est pas celui qui plante — c'est celui qui ne plante pas, corrompt une donnée voisine, et se manifeste bien plus tard, ailleurs, sous une forme incompréhensible.
int t[5];
int secret = 1;
printf("%p %p\n", (void*)t, (void*)&secret);
0x7ffd4c00 0x7ffd4c14 → 20 octets d'écart = 5 entiers
t[5] = 999;
printf("%d\n", secret); → 999Rien de magique : le tableau et la variable sont voisins sur la pile, et l'indice 5 tombe exactement sur la seconde. C'est le principe de toutes les attaques par débordement de tampon — écrire au-delà d'un tableau pour atteindre quelque chose de choisi, jusqu'à l'adresse de retour vue au TP 6 d'Architecture. La disposition n'est pas garantie par la norme, mais elle est parfaitement prévisible sur une machine donnée.
gcc -fsanitize=address -g journal.c && ./a.out ==12345==ERROR: AddressSanitizer: stack-buffer-overflow WRITE of size 4 at 0x7ffd4c14 thread T0 #0 0x… in main journal.c:12 Address is located in stack of thread T0 at offset 36 'tab' (line 10) <== 0 bytes to the right of this 20-byte region
Le tableau, sa ligne de déclaration, la taille de l'accès, la ligne fautive. Ce que vous avez cherché dix minutes à la main, l'outil le donne en une seconde. Le coût est un ralentissement d'environ 2, ce qui est parfaitement acceptable en développement et en test. À utiliser systématiquement, jamais en production.
void f(int t[]) { printf("%zu\n", sizeof t); } /* 8 : un POINTEUR */
int main(void) {
int t[5];
printf("%zu\n", sizeof t); /* 20 : le tableau entier */
f(t);
}Passé à une fonction, un tableau « dégénère » en pointeur sur son premier élément : la taille est PERDUE, définitivement. C'est pourquoi la taille doit toujours être passée à côté — et c'est aussi pourquoi la notation int t[] dans un paramètre est trompeuse : elle signifie exactement int *t. La préférer à l'étoile est un choix de lisibilité, pas de sémantique.
int par_heure[24] = {0};
/* sans contrôle : une heure lue à 99 écrit hors du tableau */
par_heure[heure]++;
/* protégé */
if (heure < 0 || heure >= 24) { lignes_invalides++; continue; }
par_heure[heure]++;La donnée vient d'un fichier, donc de l'extérieur, donc elle n'est pas fiable. La règle est générale : toute valeur venue de l'extérieur — fichier, réseau, argument, saisie — est validée AVANT de servir d'indice, de taille ou de longueur. C'est le même principe que la validation de strtol au TP 2, et il ne souffre aucune exception.
/* avant */ int somme(int t[]); /* après : taille explicite, et const quand on ne modifie pas */ int somme(const int *t, size_t n); somme accepte désormais un tableau constant, et le compilateur REFUSE toute écriture dans t à l'intérieur de la fonction
const est une vérification gratuite, faite à la compilation, et c'est aussi de la documentation qui ne peut pas devenir fausse. size_t plutôt que int pour une taille évite les valeurs négatives — au prix de la vigilance sur les comparaisons signé/non signé du TP 2.
Ce que la suite en fait
Le chapitre 6 applique tout cela au cas particulier le plus répandu : une chaîne de caractères
est un tableau de char, avec une convention supplémentaire — un marqueur de fin. Les pièges de
ce chapitre s'y aggravent, parce que la longueur n'est plus une donnée mais un résultat à
calculer.
Le chapitre 7 expliquera enfin pourquoi un tableau passé en paramètre devient un pointeur, et le chapitre 8 lèvera la dernière limite : allouer un tableau dont la taille n'est connue qu'à l'exécution.
À retenir
Flashcards · 4 cartes
- Que se passe-t-il exactement lors d'un accès hors bornes en C ?
- Rien de particulier : T[i] est traduit en « adresse de T + i × taille d'un élément », sans aucun test — vérifier coûterait une comparaison par accès, que le C refuse de payer. L'accès atteint donc la mémoire voisine. Trois issues : page interdite et ERREUR DE SEGMENTATION (le meilleur cas, l'erreur est immédiate) ; autre variable écrasée et corruption silencieuse ; adresse de retour écrasée, et c'est le débordement de tampon exploitable.
- Pourquoi sizeof(T)/sizeof(T[0]) échoue-t-il dans une fonction ?
- Parce qu'un tableau passé en paramètre se convertit en POINTEUR sur son premier élément : int T[] est strictement équivalent à int *T. sizeof(T) rend alors 8, la taille d'un pointeur, et le calcul donne invariablement 2 sur des int. L'idiome ne fonctionne que dans la portée où le tableau a été DÉCLARÉ. D'où la règle : la taille voyage avec le tableau, en second paramètre.
- Un tableau passé en paramètre est-il copié ? Est-ce une entorse au passage par valeur ?
- NON copié : ce qui est copié est l'ADRESSE de son premier élément, donc la fonction travaille sur l'original et peut le modifier. Ce n'est pas une entorse au passage par valeur — l'adresse, elle, est bien copiée — mais une conséquence de la conversion tableau-pointeur. Avantage : passer un grand tableau coûte 8 octets. Pour interdire la modification, on écrit const int T[].
- Comment un tableau à deux dimensions est-il rangé, et quelle conséquence pratique ?
- LIGNE PAR LIGNE, dans une mémoire linéaire : l'adresse de grille[i][j] vaut début + (i × nbColonnes + j) × sizeof(élément). Conséquence mesurable : parcourir PAR LIGNES suit l'ordre mémoire et exploite le cache ; parcourir PAR COLONNES saute d'une ligne à l'autre à chaque accès et peut être plusieurs fois plus lent — pour exactement le même nombre d'opérations.