[C++] Jusqu'où les pointeurs sont-ils dangereux à manipuler ?

Le problème exposé dans ce sujet a été résolu.

Bonjour,

Dans un cours d’openclassroom, on aborde en C++ le chapitre des pointeurs :

double *pointeurA;
//Un pointeur qui peut contenir l'adresse d'un nombre à virgule

unsigned int *pointeurB;
//Un pointeur qui peut contenir l'adresse d'un nombre entier positif

string *pointeurC;
//Un pointeur qui peut contenir l'adresse d'une chaîne de caractères

vector<int> *pointeurD;
//Un pointeur qui peut contenir l'adresse d'un tableau dynamique de nombres entiers

int const *pointeurE;
//Un pointeur qui peut contenir l'adresse d'un nombre entier constant

Ce code est commenté comme suit :

Pour le moment, ces pointeurs ne contiennent aucune adresse connue. C’est une situation très dangereuse. Si vous essayez d’utiliser le pointeur, vous ne savez pas quelle case de la mémoire vous manipulez. Ce peut être n’importe quelle case, par exemple celle qui contient votre mot de passe Windows ou celle stockant l’heure actuelle. J’imagine que vous vous rendez compte des conséquences que peut avoir une mauvaise manipulation des pointeurs. Il ne faut donc jamais déclarer un pointeur sans lui donner d’adresse.

https://openclassrooms.com/fr/courses/1894236-programmez-avec-le-langage-c/1896772-declarez-les-pointeurs#/id/r-1906501

Le commentaire associé est-il véridique ?
Est-il possible de modifier son mot de passe de session par erreur en exécutant un programme C++ ?

C’est imagé mais l’idée derière est réelle.

Le mot de passe Windows n’est certainement pas contenu en mémoire en permanance !

Un programme, dans des conditions normalles courrante, n’a accès qu’a ses propres zones mémoires. Un pointeur hors de cette zone mémoire virtuelle entraine un segfault. Mais dans la norme accédé à un pointeur non initialisé est un UB, donc tout et n’importe quoi peut se produire théoriquement. Aucun comportement particulier n’est attendu, n’importe quel comportement que l’ordinateur juge ok est correcte.

+1 -0

Salut !

Je souligne les termes de @ache. C’est imagé mais l’idée derrière est réelle.

De façon générale, en 2019, un processus Windows possède un espace de mémoire virtuelle. Cela veut dire qu’il a non seulement l’illusion d’occuper tout l’espace de mémoire physique disponible, mais aussi qu’il ne peut pas modifier l’espace mémoire des autres processus (sauf en passant par des API spécifiques, bien entendu).

Plus d’infos ici : https://en.wikipedia.org/wiki/Memory_management_unit

Tu n’as donc rien à craindre si ta préoccupation concerne cette histoire de changer ton mot de passe windows par erreur. Sauf si tu écris un programme qui manipule le mot de passe de l’utilisateur Windows, ou une erreur peut te coûter cher, naturellement.

Disons que c’est l’OS qui isole les processus. Mais il a existé des OS qui n’isolaient rien du tout — DOS si mes souvenirs sont bons. Et va savoir, il existe peut-être encore des OS minimalistes et exotiques embarqués on ne sait où qui n’isolent pas leurs processus.

Bref, un UB est la porte ouverte à des problèmes. Le compilo en fait ce qu’il veut et dans le pire des cas, c’est le risque d’ouvrir la porte à des problèmes d’injection. Et cela peut être très critique.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte