Discussion :

[welcc]

Bonjour,

Débutant activement dans la programmation en C, j'ai lu à plusieurs endroits que les variables locales étaient empilés dans la pile en fonction de leur ordre de déclaration.

J'ai donc voulu mettre ça en action pour voir ce que cela donne.

Avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#include <stdio.h>
 
int main()
{
     int var;
     char buffer[20];
     printf("var : %p\n", &var);
     printf("buffer : %p\n", buffer);
}

J'obtiens :

var : 0x7fff9095f78c
buffer : 0x7fff9095f790

Puis dans un second temps, en remplaçant dans le code précédent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
     int var;
     char buffer[20];

Par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
     char buffer[20];
     int var;

J'obtiens :

var : 0x7fff720b834c
buffer : 0x7fff720b8350

Est-il donc normal que l'adresse de "var" soit dans les deux cas inférieure à l'adresse de "buffer" ?

Merci

[kwariz]

Bonjour,

Apparemment tu exhibes un exemple qui prouve que ce n'est pas le cas
Les différentes normes C89,C99,C11 ne spécifient pas (donc n'obligent en rien) un ordre précis des variables locales lorsqu'elles sont stockées dans la pile. Elles n'obligent pas d'ailleurs à ce qu'elles soient stockées dans la pile, par exemple suivant les options d'optimisation elles pourront carrément ne pas exister du tout, ou n'être stockées que dans un registre, etc ...
Le compilateur peut aussi pour des raisons d'alignement de données réorganiser l'ordre.

[welcc]

Hum d'accord !

Et avec gcc par exemple, est-il possible de forcer l'ordre des variables dans la pile ?

[kwariz]

forcer ? pas à ma connaissance, du moins pas directement ...

tu peux essayer avec une structure englobant toutes tes "variables" de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
  char str[4];
  int entier;
  double reel;

tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  struct {
    char str[4];
    int entier;
    double reel;
  } mes_var_locales;

Mais je n'en vois pas l'intérêt ? Pourquoi voudrais-tu interférer avec les décisions du compilateur (qui a priori seront souvent meilleures que celles que nous pourrions prendre) ?

[welcc]

En effet ! ça marche chez moi

C'est vrai que ça doit pas servir à grand chose, c'était par pure curiosité à vrai dire. Merci pour ces réponses

[Pop360]

Bonjour, comme l'a dit kwariz ça peut dépendre de beaucoup de choses.

Toutefois voilà le concept de base (du moins sur une architecture x86)

Il y a globalement 5 segments de mémoire (d'où les segmentation fault ^^).

Les voici en partant des adresse basses (plus proche de 0) vers les adresse hautes :

-Le segment de texte (ou "segment de code") dans lequel se trouve toutes les instructions du langage machine.

-Le segment de données, qui contient les variables globales et statiques initialisées.

-Le bss qui contient les variables globales et statiques non-initialisées

-Le tas qui contient toutes les variables allouées (sur le tas, car on peut aussi allouer sur la pile)

-Et la pile, qui contient les variables locales et les appels de fonctions.

Si deux variables d'un même segment sont déclarées l'une après l'autre il peut être difficile de déterminer si la première a une adresse plus basse ou plus haute que l'autre; et ce parce que éffectivement même le compilateur peut décider lui-même.

Par exemple sur mon PC, sous windows si je fait avec un compilateur
int a;
int b;

alors &a > &b. Or ceci est l'inverse si je compile le même code sur linux avec un autre compilateur (g++).

Après, sur une architecture x86, logiquement le tas et la pile grandissent (quand on ajoute des variables) dans deux directions opposées : le tas vers les adresses en mémoire hautes, et la pile vers les adresses basses (pour minimiser l'espace gaspillé). Mais en testant avec 2 variables il n'est pas dit que l'effet soit observé car trop peu de variables en jeu...