• # Quelques réponses.

    Posté par . En réponse au message question sur la structure du code que fait le compilateur (.text, .bss, .heap ...). Évalué à 3.

    j'ai lu que la taille de la pile était fixé à 8Mo, donc ca veut dire que meme si je n'utilise que 1 Mo de ma pile, j'aurais quand meme une taille de pile qui utilise 8 Mo sur ma RAM ?

    De ce que j'ai lu à droite et à gauche, j'ai l'impression qu'il s'agit d'une limite maximale, mais pas nécessairement de la taille imposée de la stack

    que ce passe t'il si j'ai besoin d'une pile plus grande ?

    Tu peux changer la limite avec ulimit -s.
    Dans l'absolu, 8Mo de pile t'assure quand même beaucoup de "stack frame" et beaucoup de place pour des variables...

    et si je dépasse les 8Mo que ce passe t'il, segmentation fault ?

    Oui.

    Seul la taille de pile est limité, ou c'est pareil aussi pour les variables globales ?

    Les variables globales sont "stockées" dans la pile, donc oui

    pourquoi sur l'image, j'ai le tas qui va venir écrire sur la pile ?

    Euh ... il ne va pas venir "écrire" sur la pile. L'image, par les flèches, veut (j'imagine) illustrer la façon dont les deux zones vont être gérée...
    Ci dessous un code d'exemple et sa sortie:

    #include <stdio.h>
    #include <stdlib.h>
    int main(int ac, char **av)
    {
     int a, b, c;
     int *d, *e, *f;
     d = malloc(sizeof(int));
     e = malloc(sizeof(int));
     f = malloc(sizeof(int));
     printf("Stack: %p %p %p\n", &a, &b, &c);
     printf("Heap: %p %p %p\n", d, e, f);
     return (0);
    }

    Résultat:
    Stack: 0x7ffcde6cadb4 0x7ffcde6cadb0 0x7ffcde6cadac
    Heap: 0x55867bd76010 0x55867bd76030 0x55867bd76050

    On voit bien que les adresses de a, b et c décroissent là ou les adresses allouées par malloc croissent.

    Dans l'absolu, pile et tas sont distincts (et doivent le rester ;-))