Pile et tas en C : différence, durée de vie, taille

« Mets ça sur le tas », « cette variable est sur la pile » : les deux mots reviennent sans cesse quand on écrit du C, souvent sans qu'on sache vraiment ce qui les sépare. La différence est concrète, et elle décide de la durée de vie de tes données, de la taille maximale que tu peux leur donner, et de qui doit les libérer.

Pile et tas : la différence en un tableau

Quatre critères suffisent à les distinguer.

La pile avance et recule au rythme des appels de fonction : entrer dans une fonction réserve un cadre (ses variables locales), en sortir le rend d'un coup. C'est pour ça qu'elle est rapide, et qu'une variable locale n'existe plus dès que sa fonction se termine. Le tas, lui, ne suit pas les appels : un bloc que tu alloues dans une fonction peut être utilisé bien plus tard, ailleurs, et ne part que quand tu le libères.

Où vit chaque variable

Le plus simple est de demander leur adresse aux variables elles-mêmes. Ce programme en déclare une de chaque sorte et affiche son adresse avec %p :

#include <stdio.h>#include <stdlib.h>
int compteur = 42;      /* globale initialisée */int total;              /* globale non initialisée */
int main(void){    int locale = 7;             /* sur la pile */    static int appels = 0;      /* locale, mais statique */    char *message = "bonjour";  /* littéral en lecture seule */    int *tas = malloc(sizeof(int)); /* bloc sur le tas */
    if (tas == NULL)        return 1;    *tas = 5;    printf("locale    %p\n", (void *)&locale);    printf("tas       %p\n", (void *)tas);    printf("total     %p\n", (void *)&total);    printf("appels    %p\n", (void *)&appels);    printf("compteur  %p\n", (void *)&compteur);    printf("message   %p\n", (void *)message);    printf("main      %p\n", (void *)main);    free(tas);    return 0;}

$ gcc -Wall -Wextra -g zones.c -o zones$ ./zoneslocale    0xfffff2253c7ctas       0x425a2a0total     0x420048appels    0x42004ccompteur  0x420040message   0x4007c8main      0x4006c4

Range ces adresses par ordre de grandeur et la carte de la mémoire apparaît. Tout en haut, locale, vers 0xfffff... : c'est la pile, qui part des adresses hautes. Beaucoup plus bas, tas, vers 0x42...a0 : le tas, juste au-dessus de la zone statique. Puis un petit groupe serré, total, appels et compteur, autour de 0x420040 : la zone statique, là où vivent les globales et les variables static. Enfin message et main, vers 0x400... : la chaîne littérale et le code, dans la partie en lecture seule du programme.

Deux relances de suite montrent un détail utile : les adresses de la pile et du tas changent à chaque exécution (c'est l'ASLR, qui déplace ces zones pour la sécurité), alors que celles de la zone statique et du code restent identiques.

Pour suivre ce découpage pas à pas sur un vrai programme, le visualiseur de Grademe montre la pile, le tas et les pointeurs qui les relient à chaque ligne :

#include <stdlib.h>
int global = 42;
int main(void){    int locale = 7;    int *copie = malloc(sizeof(int));
    if (copie == NULL)        return 1;    *copie = locale;    free(copie);    return 0;}

La taille : pourquoi un gros tableau local plante

La pile a une taille maximale, que ulimit -s affiche en kilo-octets :

$ ulimit -s8192

8192 Ko, soit 8 Mo. C'est confortable pour des variables ordinaires, mais pas pour un gros tableau local. Ce programme déclare un tableau de 16 Mo sur la pile :

#include <stdio.h>#include <string.h>
int main(void){    char image[16 * 1024 * 1024];
    memset(image, 0, sizeof(image));    printf("image prête : %zu octets\n", sizeof(image));    return 0;}

$ gcc -Wall -Wextra -g grand.c -o grand$ ./grandSegmentation fault

Le tableau dépasse les 8 Mo de la pile, le premier accès au-delà de la limite déclenche le signal. La même donnée sur le tas passe sans problème, parce que le tas n'a pas cette limite étroite :

$ ./grand-tasimage prête : 16777216 octets

grand-tas.c est le même programme avec un malloc(16 * 1024 * 1024) à la place du tableau local. La règle pratique : dès qu'une donnée est grosse ou que sa taille n'est connue qu'à l'exécution, c'est le tas qu'il faut, pas la pile.

Renvoyer une adresse de pile : le bug classique

Puisqu'une variable locale disparaît à la fin de sa fonction, renvoyer son adresse donne un pointeur vers une case qui ne t'appartient plus. C'est une des causes les plus fréquentes de segmentation fault, et GCC la détecte souvent :

#include <stdio.h>#include <string.h>
char *copie(const char *source){    char tampon[32];
    strcpy(tampon, source);    return tampon;      /* tampon meurt ici */}
int main(void){    char *s = copie("bonjour");
    printf("%s\n", s);    return 0;}

$ gcc -Wall -Wextra -g renvoi.c -o renvoirenvoi.c: In function 'copie':renvoi.c:9:12: warning: function returns address of local variable [-Wreturn-local-addr]    9 |     return tampon;      /* tampon meurt ici */      |            ^~~~~~$ ./renvoiSegmentation fault

Le pointeur s dans main vise une zone de pile déjà rendue : l'utiliser est un comportement indéfini. La solution est de mettre le résultat sur le tas, avec malloc, et de laisser l'appelant le libérer. Les deux exercices ci-dessous travaillent les deux côtés de cette frontière : l'un distribue la mémoire à la main, l'autre rend visible la pile des cadres.

arena_alloc

Écris un allocateur « bump » qui sert des tranches alignées sur 8 depuis un pool static de 4096 octets, sans jamais appeler malloc. Tu manipules à la main la frontière entre ce qui est donné et ce qui reste libre : la meilleure façon de comprendre ce qu'un allocateur fait au tas.

Ouvrir l'exercice

descend

descend(n, ...) s'appelle de n jusqu'à 1 en signalant chaque niveau à la descente puis à la remontée. Les appels qui remontent sortent dans l'ordre inverse de ceux qui descendent : c'est la pile des cadres de fonction, rendue visible.

Ouvrir l'exercice

Questions fréquentes