Possibilité de contourner le spécificateur private ?!!Résolu

Question

Salut à tous et à toutes 

exécutez ce code et vous verrez que public_string pointe sur private_string : est-ce un bug dans C++ ? 

code testé sous Windows XP, compilé sous Visual C++ 6..

#include 
#include <string.h>

class A
{
private :
    char *private_string;
public :
    


char 



*public_string;
    A()
    {
        public_string = new 



char



[10];
        delete(public_string);

        private_string = 



new 




char



[10];
        strcpy(private_string, "Chatbour");
        private_string[8] = '\0';
    }

    void afficher()
    {
        cout<void main()
{
    A a;

    a.afficher();

    a.public_string[0] = 'c';

    a.afficher();

}





Vos commentaires..

_____________________
Vos avis et critiques sur le livre "Objets réactifs en java" de Frédéric Boussinot : contactez moi par MP..
http://books.go%3C/body

SAKingdom · Accepted Answer

Non ce n'est pas un bogue. 
Tu alloues de la mémoire pour public_string que tu libères ensuite. Puis tu alloues pour private_string exactement la même quantité de mémoire. L'allocateur verra cette zone mémoire fraîchement libérée de taille identique disponible et la réservera pour private_string.
Cependant, ce comportement n'est pas garanti. Cette zone mémoire peut-être réservée par un autre thread, par exemple, si un changement de contexte a lieu entre le delete et le new.

C++ (@++)<!--

cs_Chatbour · Answer

ok, mais c'est une source de problèmes..

je pense que si on doit considérer ceci comme bogue, ça doit être de la part du système..

_____________________
Vos avis et critiques sur le livre "Objets réactifs en java" de Frédéric Boussinot : contactez moi par MP..
http://books.go%3C/body

SAKingdom · Answer

Non ce n'est pas un problème. Il est trop difficile de prévoir ce genre de comportement pour l'exploiter facilement. 

"je pense que si on doit considérer ceci comme bogue, ça doit être de la part du système.."

L'accès au attributs ne veut strictement rien dire pour le système. Tout ça est réglé durant la compilation et non durant l'exécution. Le système ne fait qu'allouer la mémoire et ne se demande pas si une variable dite "privée" avait cette zone avant. Ce concept d'accès aux attributs n'est pas applicable au niveau de l'exécution mais seulement lors de la conception du code source.

Si tu veux être sûr que public_string ne soit plus utilisable, assigne lui 0 après le delete.

C++ (@++)<!--

MuPuF · Answer

Hello,

En fait, c'est ta logique qui est mauvaise. Quand on libère de la mémoire, on ne doit plus essayer de la lire après car le comportement n'est pas garanti. Or, c'est ce que tu fais.

Comme l'a bien dit SAKingdom, ton programme n'est pas le seul à tourner --> le 2ème new pourrait te donner une zone mémoire totalement différente.

A moins que ce soit le compilo qui voit qu'il peut reutiliser la zone mémoire fraichement libérée et donc éviter une alloc. Seule une analyse du code asm pourrait donc nous dire si c'est le compilo ou le kernel qui est à l'origine de cette "bizarrerie".

Quoi qu'il en soit, c'est sympa comme sujet.

Bye

/* MuPuF® Mon Tech-blog : www.mupuf.fr.nf

cs_juju12 · Answer

par contre cela n'a rien à voir avec le fait que d'autres programmes soient en cours d'exécution...n'oublions pas qu'il s'agit de mémoire virtuelle. Mais comme disait SAKingdom, s'il y a d'autres threads dans le même programme, l'adresse pourrait être réservée dans l'intervalle.

MuPuF · Answer

En effet juju12, faut que je continue à en apprendre plus sur le kernel (je suis en pleine lecture de "Understanding the Linux Kernel"). Je me la ferme donc la dessus ;)

/* MuPuF® Mon Tech-blog : www.mupuf.fr.nf

SAKingdom · Answer

Tien un petit test pour montrer ce que je voulais dire par :
"Ce concept d'accès aux attributs n'est pas applicable au niveau de
l'exécution mais seulement lors de la conception du code source."

class Test {
public:
    Test(char *i, int j, char k) {
        pointeur = i;
        entier = j;
        carac = k;
    }
private:
    char *pointeur;
    int entier;
    char carac;
};
    

int main (int argc, char *argv[]) {
    Test *ttt = new Test("Bonjour les amis", 234, 'e');
    char *i = *(char**)ttt;
    int j = *(int*)((char*)ttt+4);
    char k = *(char*)((char*)ttt+8);
    
    cout << i << '
' << j << '
' << k << endl;
}

Compilé avec g++ et testé sous linux. Devrait t'afficher:

Bonjour les amis
234
e

Le concept d'encapsulation n'a de sens que dans la conception du programme et non lors de son exécution.

C++ (@++)<!--

cs_Chatbour · Answer

vous savez quoi : java a raison d'éliminer les pointeurs 

_____________________
Vos avis et critiques sur le livre "Objets réactifs en java" de Frédéric Boussinot : contactez moi par MP..
http://books.go%3C/body

cs_Chatbour · Answer

la prochaine version de C++ va-t-elle peut être corriger ces lacunes ?


_____________________
Vos avis et critiques sur le livre "Objets réactifs en java" de Frédéric Boussinot : contactez moi par MP..
http://books.go%3C/body

SAKingdom · Answer

Du fais que Java n'a pas de pointeur, des manipulations excessivement plus coûteuse sont nécessaire pour arriver au même résultat (par exemple, devoir passer par une méthode pour extraire un simple caractère du chaine). Java est aussi beaucoup plus lourd n'en déplaise au adepte de ce langage. Mauvais exemple de comparer un langage interprété avec un langage compilé.

Les pointeurs ne sont pas une lacune. Une utilisation judicieuse permet de tout faire (ou presque) et c'est le point fort du langage. Interdire des manipulations de la sorte revient à limiter le langage ce qui n'est pas une très bonne idée.

C++ (@++)<!--

Possibilité de contourner le spécificateur private ?!!

10 réponses

Votre réponse

Discussions similaires