C Portée de chaîne affectée par une pile

Question

Pour les chaînes droites C et GCC, pourquoi la chaîne pointée n'est-elle pas corrompue ici?

#include <stdio.h> 

int main(int argc, char *argv[]) 
{ 
    char* str_ptr = NULL; 

    { 
     //local to this scope-block 
     char str[4]={0}; 
     sprintf(str, "AGH"); 

     str_ptr = str; 
    } 

    printf("str_ptr: %s\n", str_ptr); 

    getchar(); 
    return 0; 
} 

| ---- SORTIE ----- |

str_ptr: AGH 

| -------------------- |

Voici a link au code ci-dessus compilé et exécuté en utilisant un compilateur en ligne. Je comprends que si str était un littéral de chaîne, str serait stocké dans le bss (essentiellement statique), mais sprintf (ing) dans un tampon alloué par pile, je pensais que le tampon de chaîne serait purement stack- basé (et donc l'adresse sans signification après avoir quitté le bloc de portée)? Je comprends qu'il peut prendre des allocations de pile supplémentaires pour écraser la mémoire à l'adresse donnée, mais même en utilisant une fonction récursive jusqu'à un dépassement de pile, je n'ai pas pu corrompre la chaîne pointée par str_ptr.

FYI Je fais mes tests dans un projet VS2008 C, bien que GCC semble avoir le même comportement.

Answer 1

Il est probable que le compilateur effectue une sorte d'optimisations simples, ce qui fait que la chaîne se trouve toujours au même endroit sur la pile. En d'autres termes, le compilateur permet à la pile de se développer pour stocker 'str'. Mais il ne réduit pas la pile dans le cadre de main, car il n'est pas obligé de le faire.

Si vous voulez vraiment voir le résultat de l'enregistrement de l'adresse des variables sur la pile, appelez une fonction.

#include <stdio.h> 

char * str_ptr = NULL; 
void onstack(void) 
{ 
    char str[4] = {0}; 
    sprintf(str,"AGH"); 
    str_ptr = str; 
} 

int main(int argc, char *argv[]) 
{ 

    onstack(); 
    int x = 0x61626364; 
    printf("str_ptr: %s\n", str_ptr); 
    printf("x:%i\n",x); 
    getchar(); 
    return 0; 
} 

Avec gcc -O0 -std=c99 strcorrupt.c Je reçois une sortie aléatoire sur le premier printf. Cela va varier d'une machine à l'autre et de l'architecture à l'architecture.

Answer 2

Alors que les lézards nasaux sont une partie populaire du folklore C, le code dont le comportement n'est pas défini peut en fait présenter n'importe quel comportement, y compris des variables ressuscitant magiquement dont la durée de vie a expiré. Le fait que le code avec un comportement indéfini puisse sembler "fonctionner" ne devrait être ni surprenant ni une excuse pour négliger de le corriger. Généralement, à moins que vous n'ayez à écrire des compilateurs, il n'est pas très utile d'examiner la nature précise d'un comportement indéfini dans un environnement donné, d'autant plus que cela peut être différent après avoir clignoté.

Dans ce cas particulier, l'explication est simple, mais il s'agit d'un comportement non défini, donc l'explication suivante ne peut pas être invoquée du tout. Il pourrait à tout moment être remplacé par des émissions reptiliennes. De manière générale, les compilateurs C feront de la taille de la pile de chaque fonction une valeur fixe, plutôt que de se dilater et de se contracter lorsque le flux de contrôle entre et sort des blocs internes. À moins que les fonctions appelées ne soient en ligne, leurs trames de pile ne chevaucheront pas le cadre de pile de l'appelant. Ainsi, dans certains compilateurs C avec certains ensembles d'options de compilation et à l'exception de phases particulières de la lune, le tableau de caractères str ne sera pas remplacé par l'appel à printf, même si la durée de vie de la variable a expiré.