pourquoi ce pointeur change-il d'adresse

[zaskzask]

Bonjour,

Dans le code suivant, l'operation q=p+2 change l'adresse a laquelle pointe q et lui met en adresse la valeur de p (i.e. 0xAA)

    
    int a;
    int* p;
    p=&a;
    printf("p=%p",p); // on obtient p=0x22ff10
    int* q;
    q=p+2;
    (*q)=0xAA;
    printf("p=%p",p); // on obtient p=0xAA

p=0xAA (mais selon moi p devrait rester 0x22ff10)
Pourquoi a-t-on ce comportement?
-----

[Bluedeep]

Bonjour

Dans la mesure ou on ne sait pas où tape p+2, il est difficile de prédire ce qui se passe quand on modifie "à l'aveugle" la mémoire à cet endroit.

q est justement définit quelques octets plus loin que a (2xsizeof(int) justement) , ce n'est pas forcément étonnant (ce code étant par nature "unsafe").

En fait un printf de &q tu aurais peut être la réponse (que (*q) modifie q justement.

Essaye de rajouter juste après la déclaration de a char buffer[100] pour voir.

[Chanur]

Manifestement, dans le cas que tu présentes, p est située 8 octets plus loin que a (je présume que les "int" font 4 octets).
C'est assez logique puisque les pointeurs, de nos jours font en général 8 octets.

Donc, quand tu fais q = p+2, sachant que p contient l'adresse de a, tu tombes sur l'adresse de p.
et quand tu fais *q=0xAA, tu modifie p.

[Logoosse]

Bonsoir,
dis moi pourrais tu initialiser ton a juste avant de mettre l'addresse de p dans a et nous dire si ton adresse change toujours dans p ?

[A voir en vidéo sur Futura]

[Chanur]

mettre l'addresse de p dans a

?
Mettre une adresse dans un int ?

[Logoosse]

Oups erreur de relecture je voulais juste lui demander d'initialiser a entre la deuxième et troisième ligne.

Car j'ai tester son programme, et j'ai pas de changement d'adresse du coup je me suis juste demander si le fait qu'il initialise pas a fait que les manip d'après le font tenter d'acceder à une zone dont il n'a pas accès et en réponse le système re-allocate les variable ^^.

[Chanur]

Oups erreur de relecture je voulais juste lui demander d'initialiser a entre la deuxième et troisième ligne.

Car j'ai tester son programme, et j'ai pas de changement d'adresse du coup je me suis juste demander si le fait qu'il initialise pas a fait que les manip d'après le font tenter d'acceder à une zone dont il n'a pas accès et en réponse le système re-allocate les variable ^^.

Il n'y a aucune norme sur l'ordre dans lequel les variables sont stockées en mémoire. C'est absolument pas portable.
En fait, pour un même compilateur, ça dépend des options de compilation (par exemple l'optimiseur a tout à fait le droit de supprimer purement et simplement une variable. Alors l'ordre de stockage ...)

[pm42]

Sur ma machine, *p ne change pas mais comme déjà dit, à code aléatoire, résultat aléatoire.
Vu qu'on parle de valeurs sur la pile, le code fait vraiment n'importe quoi.

[Logoosse]

Il n'y a aucune norme sur l'ordre dans lequel les variables sont stockées en mémoire. C'est absolument pas portable.
En fait, pour un même compilateur, ça dépend des options de compilation (par exemple l'optimiseur a tout à fait le droit de supprimer purement et simplement une variable. Alors l'ordre de stockage ...)

Je parle pas de norme de stockage, j'insinue justement que comme il y en a pas au moment ou il créer son int et qu'il n'est pas initialisé, celui ci pointe sur une ressource système critique (comme aucune norme celà peut arriver), au moment où il modifie q qui pointe peut être encore sur la suite de cette ressource critique (q*) modifie la valeur donc il initialise un int dans une ressource peut être critique le système derriere lui répond en réallouant ses variables ^^.

mais le fait d'initialiser a changerait rien, car q pose problème également.

[Logoosse]

Je ne peux plus modifier ma réponse, mais quand je dis le système j’inclus (l'os, un programme tiers, l'ide, etc) qui peuvent prévenir des dommages que pourrait causer un dangling pointer ou un buffer overflow.

[pm42]

C'est difficilement compréhensible mais l'OS, l'IDE ou un programme tiers étaient capables de réallouer les pointeurs pour empêcher la modification d'une ressource critique, cela se saurait...
Déjà, la mémoire accessible à un programme ne contient pas de ressource critique. Ensuite, les programmes tiers n'ont pas accès à la dite mémoire. L'IDE ne fait pas ça non plus...

[Chanur]

Mais je ne comprends pas bien ce que tu veux dire : le fait d'utiliser un pointeur vers une variable n'a aucun rapport avec le fait de savoir si cette variable est initialisée ou pas.

Par exemple

int i;
scanf ("%d", &i);

est parfaitement valide.

Et on peut passer par un pointeur intermédiaire :

int i;
int * p = &i;
scanf ("%d", p);

C'est tout aussi valide : la variable i est allouée sur la stack à l'appel de la fonction. A partir de ce moment, et jusqu'au return, on peut utiliser son adresse.
Ce qu'on ne peut pas faire c'est présumer de la valeur de son adresse par rapport à celle d'une autre variable.

[Chanur]

(je n'avais pas vu le message de pm42, je répondais, bien sûr à Logoosse)

[Logoosse]

Je concède, juste un comportement inexplicable du au wild pointer.