Votre variable dn'est généralement pas sautée de la pile. Les accolades bouclées ne désignent pas un cadre de pile. Sinon, vous ne pourriez pas faire quelque chose comme ceci:
char var = getch();
{
char next_var = var + 1;
use_variable(next_char);
}
Si les accolades provoquaient un véritable push / pop de pile (comme le ferait un appel de fonction), alors le code ci-dessus ne se compilerait pas car le code à l'intérieur des accolades ne serait pas en mesure d'accéder à la variable varqui vit en dehors des accolades (tout comme un sous- ne peut pas accéder directement aux variables de la fonction appelante). Nous savons que ce n’est pas le cas.
Les accolades bouclées sont simplement utilisées pour la portée. Le compilateur traitera tout accès à la variable "interne" depuis l'extérieur des accolades englobantes comme invalide, et il pourra réutiliser cette mémoire pour autre chose (cela dépend de l'implémentation). Cependant, il ne peut pas être détaché de la pile avant le retour de la fonction englobante.
Mise à jour: voici ce que la spécification C a à dire. Concernant les objets à durée de stockage automatique (section 6.4.2):
Pour un objet qui n'a pas de type tableau de longueur variable, sa durée de vie s'étend de l'entrée dans le bloc auquel il est associé jusqu'à ce que l'exécution de ce bloc se termine de toute façon.
La même section définit le terme «durée de vie» comme (c'est moi qui souligne):
La durée de vie d'un objet est la partie de l'exécution du programme pendant laquelle il est garanti que le stockage lui est réservé. Un objet existe, a une adresse constante et conserve sa dernière valeur stockée pendant toute sa durée de vie. Si un objet est référencé en dehors de sa durée de vie, le comportement n'est pas défini.
Le mot clé ici est, bien entendu, «garanti». Une fois que vous quittez la portée de l'ensemble interne d'accolades, la durée de vie du tableau est terminée. Le stockage peut ou non lui être encore alloué (votre compilateur peut réutiliser l'espace pour autre chose), mais toute tentative d'accès au tableau invoque un comportement non défini et entraîne des résultats imprévisibles.
La spécification C n'a aucune notion de cadres de pile. Il ne parle que de la façon dont le programme résultant se comportera et laisse les détails de l'implémentation au compilateur (après tout, l'implémentation serait assez différente sur un processeur sans pile que sur un processeur avec une pile matérielle). Il n'y a rien dans la spécification C qui impose où un cadre de pile se terminera ou non. Le seul vrai moyen de le savoir est de compiler le code sur votre compilateur / plateforme particulier et d'examiner l'assembly résultant. L'ensemble actuel d'options d'optimisation de votre compilateur jouera probablement également un rôle à cet égard.
Si vous voulez vous assurer que le tableau dne consomme plus de mémoire pendant l'exécution de votre code, vous pouvez convertir le code entre accolades en une fonction distincte ou explicitement mallocet freela mémoire au lieu d'utiliser le stockage automatique.