Où sont stockées les variables statiques en C et C++ ?

Question

Dans quel segment (.BSS, .DATA, autre) d'un fichier exécutable les variables statiques sont-elles stockées afin qu'elles n'aient pas de collision de noms ? Par exemple :

foo.c:                         bar.c:
static int foo = 1;            static int foo = 10;
void fooTest() {               void barTest() {
  static int bar = 2;            static int bar = 20;
  foo++;                         foo++;
  bar++;                         bar++;
  printf("%d,%d", foo, bar);     printf("%d, %d", foo, bar);
}                              }

Si je compile les deux fichiers et que je les lie à un main qui appelle fooTest() et barTest à plusieurs reprises, les instructions printf s'incrémentent indépendamment. C'est logique puisque les variables foo et bar sont locales à l'unité de traduction.

Mais où le stockage est-il alloué ?

Pour être clair, l'hypothèse est que vous avez une chaîne d'outils qui produirait un fichier au format ELF. Ainsi, je croire qu'il y a a il doit y avoir un espace réservé dans le fichier exécutable pour ces variables statiques.
Pour les besoins de la discussion, supposons que nous utilisons la chaîne d'outils GCC.

Answer 1

L'endroit où vont vos statiques dépend du fait qu'elles soient zéro initialisé . zéro initialisé les données statiques vont dans .BSS (Bloc démarré par un symbole) , non-zéro-initialisé les données sont introduites .DATA

Answer 2

Lorsqu'un programme est chargé en mémoire, il est organisé en différents segments. L'un des segments est Segment DATA . Le segment des données est encore subdivisé en deux parties :

Segment de données initialisé : Toutes les données globales, statiques et constantes sont stockées ici.
Segment de données non initialisé (BSS) : Toutes les données non initialisées sont stockées dans ce segment.

Voici un schéma pour expliquer ce concept :

Voici un très bon lien expliquant ces concepts :

http://www.inf.udec.cl/~leo/teoX.pdf

Answer 3

En fait, une variable est un tuple (stockage, portée, type, adresse, valeur) :

storage     :   where is it stored, for example data, stack, heap...
scope       :   who can see us, for example global, local...
type        :   what is our type, for example int, int*...
address     :   where are we located
value       :   what is our value

La portée locale peut signifier locale à l'unité de translation (fichier source), à la fonction ou au bloc selon l'endroit où elle est définie. Pour rendre une variable visible par plus d'une fonction, elle doit absolument se trouver dans la zone DATA ou BSS (selon qu'elle est initialisée explicitement ou non, respectivement). Sa portée est alors adaptée soit à toutes les fonctions, soit aux fonctions du fichier source.

Answer 4

L'emplacement de stockage des données dépendra de l'implémentation.

Cependant, la signification de statique est "lien interne". Ainsi, le symbole est interne à l'unité de compilation (foo.c, bar.c) et ne peut être référencé en dehors de cette unité de compilation. Il ne peut donc pas y avoir de collision de noms.

Answer 5

Je ne crois pas qu'il y aura une collision. L'utilisation de static au niveau du fichier (en dehors des fonctions) marque la variable comme locale à l'unité de compilation actuelle (fichier). Elle n'est jamais visible en dehors du fichier actuel et n'a donc jamais besoin d'avoir un nom qui puisse être utilisé en externe.

Utilisation d'un système statique à l'intérieur de une fonction est différente - la variable n'est visible que pour la fonction (qu'elle soit statique ou non), c'est juste sa valeur qui est préservée à travers les appels à cette fonction.

En effet, la statique fait deux choses différentes selon l'endroit où elle se trouve. Sur les deux Cependant, dans les cas où la visibilité des variables est limitée, vous pouvez facilement éviter les conflits d'espace de noms lors de l'établissement de liens.

Cela dit, je pense qu'elle serait stockée dans le fichier DATA qui a tendance à avoir des variables qui sont initialisées à des valeurs autres que zéro. Il s'agit, bien entendu, d'un détail d'implémentation, et non d'un élément imposé par la norme - elle ne s'intéresse qu'à comportement, pas comment les choses sont faites sous la couverture.