Discussion :

[jldgbu]

Quelqu'un arrive-t-il � expliquer le comportement ce code un fois compil� (avec g++) puis ex�cuter:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
int main()
{
	const int a = 2;
	int * pa;
	const int * cpa;
 
	cpa = &a;
	pa = (int*)cpa; //Pour gruger le mot clé const
	*pa = 4;
 
	printf("a = %d\n", a);
	printf("*pa = %d\n", *pa);
 
	return 0;
}

On a alors la sortie suivante :

a = 2
*pa = 4

Pourquoi n'a-t-on pas :

a = 4
*pa = 4

pa est cens� point� le contenu de a ?
c'est d'ailleurs le r�sultat obtenu avec gcc...

[Flob90]

Tu veus encore plus �tonnant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
const int ca = 0;
int& ra = const_cast<int&>(ca);
++ra;
std::cout << ra << ca;
std::cout << &ra << &ca;

Les objets sont � la m�me adresse mais n'ont pas la m�me valeur !
Je suis pas certain (pas r�ussi � v�rifier dans la norme), mais je crois que quand tu d�finis une variable constante sur un type fondamentale alors la valeur est imuable quoique tu fasses. (comment je sais pas, soit il remplace de mani�re lit�ral mais j'en doute, soit il stoocke la variable dans une table innaccesible et l'utilise d�s qu'il voit la variable nue, ie ca).

[jblecanard]

Salut

Si tu regardes le code assembl� (avec visual studio) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
	printf("a = %d\n", a);
004113DA  mov         esi,esp 
004113DC  push        2    
004113DE  push        offset string "a = %d\n" (41580Ch)

L� ou a est utilis�, le compilo met directement en dur la valeur que tu lui a donn� � son initialisation. C'est tr�s bien d'ailleurs, car c'est mal de vouloir gruger const

[white_tentacle]

C'est pas un comportement ind�fini de vouloir modifier la valeur d'une constante manifeste ?

[jldgbu]

Je ne pense pas que cela soit en rapport avec la norme, mais plut�t d� � des optimisations de compilateur.

Si je compile avec gcc sans optimisation (-O0 ou rien) j'ai le r�sultat attendu :

4
4

si j'utilise gcc avec optimisation (-O1,2,3...) j'ai la m�me chose qu'avec g++ :

2
4

Par contre ce qui me d�range avec g++ c'est que sans options d'optimisation (-O0 ou rien par d�fault) on devrait avoir :

4
4

or ce n'est pas le cas, que l'on utilise -O0,1,2,3... ou rien on a toujours le m�me r�sultat

[jblecanard]

Je ne pense pas que cela soit en rapport avec la norme, mais plut�t d� � des optimisations de compilateur.

Si �a a � voir car � partir du moment ou tu es dans un comportement ind�fini, le compilateur a le droit de faire ce qui lui pla�t, il ne te doit strictement rien. Donc �a varie d'un compilo � un autre, c'est logique et �a ne devrais pas te poser de souci car dans un code propre, on ne modifie pas des const .

[bacelar]

T'as jou� au plus malin avec le compilateur et t'as perdu.

[jldgbu]

T'as jou� au plus malin avec le compilateur et t'as perdu.

Mon probl�me n'est pas de jouer au plus malin avec un compilateur mais de m'assurer que personne ne peut changer une variable const que j'exposerai par quelques bidouilles que ce soit...

[jblecanard]

Mon probl�me n'est pas de jouer au plus malin avec un compilateur mais de m'assurer que personne ne peut changer une variable const que j'exposerai par quelques bidouilles que ce soit...

Si t'as des programmeurs qui bricolent pour modifier tes const, c'est qu'il y a un probl�me autre � mon avis, qui tient � l'organisation et aux r�gles de codage � respecter.

En plus tu vois qu'avec g++, on a bien le comportement de const non modifi�, donc aucun souci si tu utilises g++ non ?

[white_tentacle]

Mon probl�me n'est pas de jouer au plus malin avec un compilateur mais de m'assurer que personne ne peut changer une variable const que j'exposerai par quelques bidouilles que ce soit...

La philosophie de C++, c'est plut�t "protect agains murphy, not machiavel". const suit cette philosophie.

Si tu veux vraiment t'assurer que personne ne modifie une variable const que tu exposes, le meilleur moyen que je vois est d'en renvoyer une copie � chaque fois, et de ne pas exposer la source. Mais m�me �a, �a se contourne.

[jldgbu]

Si tu veux vraiment t'assurer que personne ne modifie une variable const que tu exposes, le meilleur moyen que je vois est d'en renvoyer une copie � chaque fois, et de ne pas exposer la source. Mais m�me �a, �a se contourne.

? Je suis curieux t'as un exemple de code ?

[Klaim]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

 MonTruc truc() { return m_truc; } // copie, pas d'accès a direct a truc

[jldgbu]

Euh c'�tait pas �a ma question, je sais comment renvoyer une copie pour ne pas exposer la source mais plut�t un exemple qui montre comment contourner �a.

[NoIdea]

Apr�s quelques tests, on peut se rendre compte que la norme C99 et c++ doivent �tre diff�rentes a propos des const :

Le programme suivant compile (avec gcc) avec un seul warning alors que avec g++, il donne une erreur.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#include <stdlib.h>
#include <stdio.h>
 
const char*prouver_const(const char* chn)
{
    char*chn2=chn;
    chn2[0]='T';
    return chn;
}
 
 
int main()
{
    char*chn=malloc(6);
    strcpy(chn,"tests");
    printf("%s",prouver_const(chn));
 
}

De plus, le programme suivant lui, affiche "bug" :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdlib.h>
#include <stdio.h>
 
 
int main()
{
    char *chn="test";//L'allocation est automatique si c'est à la déclaration je crois.
    printf("%s",chn);
    chn=realloc(chn,6);
    if(!chn)
        printf("bug");
}

Quelqu'un pourrait-il l'expliquer ?

[gl]

De plus, le programme suivant lui, affiche "bug" :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdlib.h>
#include <stdio.h>
 
 
int main()
{
    char *chn="test";//L'allocation est automatique si c'est à la déclaration je crois.
    printf("%s",chn);
    chn=realloc(chn,6);
    if(!chn)
        printf("bug");
}

Quelqu'un pourrait-il l'expliquer ?

Il n'y a pas d'allocation automatique. Tu cr�es juste un pointeur que tu l'initialise avec l'adresse du cha�ne constante.

chn contenant l'adresse d'une cha�ne constante et non une adresse retourn� par malloc() (ou �quivalent) ni NULL, l'appel � realloc() est un comportement ind�fini :

Otherwise, if ptr does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to the free or realloc function, the behavior is undefined.

Au passage, en C++ il n'est pas recommand� d'utiliser malloc(), realloc() et compagnie.

Et il est assez vain d'essayer de comprendre, d'expliquer ou de pr�dire un comportement ind�finie. Une impl�mentation est en droit de faire ce qu'elle veut et pas n�cessairement toujours la m�me chose (cela peut varier notamment en fonction du niveau d'optimisation).

[bacelar]

Et une personne malveillant n'est pas oblig�e d'utiliser vos en-t�tes, ni m�me vos m�thodes ou fonctions pour aller fouiller dans vos donn�es, ni m�me d'utiliser du code C++.

[white_tentacle]

Euh c'�tait pas �a ma question, je sais comment renvoyer une copie pour ne pas exposer la source mais plut�t un exemple qui montre comment contourner �a.

Pas d'exemple simple, d'autant que ce n'est pas le genre de choses auxquelles je m'amuse. Je sais que c'est possible en C++ (logique), mais pas en .Net (code manag�). En gros, l'id�e de base, c'est que rien ne t'emp�che d'�crire � une adresse m�moire qui t'appartient, du moment que la page est inscriptible. Donc si la valeur est allou� � l'ex�cution (ie, pas dans la zone data du programme), le programme peut la modifier.

Apr�s, la difficult� principale r�side dans le fait de trouver l'adresse o� �crire. Mais ce n'est pas insurmontable. Il faut bien r�aliser, quand on fait du d�veloppement, que les fonctionnalit�s telles que const, private, etc, sont des fonctionnalit�s de v�rification statique, et aucunement de s�curit�.

[jldgbu]

Pour noIdea

Le deuxi�me programme s'explique bien par le fait qu'un realloc est fait sur des donn�es non allou�es par malloc.

Pour le premier programme :

On ne peut pas normalement affecter une valeur de pointeur constant � un pointeur non constant, sauf pour les chaines de caract�res qui font exception.

Une chaine du type

"Hello"

est une chaine de caract�res constantes, on ne devrait donc pouvoir affecter son addresse qu'� un pointeur de caract�res constant.

const char* chaine = "hello"; //plus rigoureux

Seulement en C on a pris l'habitude suivante:

char* chaine = "hello";

Donc par compatibilit� on a la conversion implicite entre "const char *" et "char *"

Par contre si tu t'amuses � modifier la chaine de caract�res constante tu pourras toujours compiler mais � l'execution l� ce sera la roulette russe. Ca plantera ou pas selon que le compilateur choisit de mettre �a dans une zone m�moire ou tu peux �crire...

[M�dinoc]

Donc par compatibilit� on a la conversion implicite entre "const char *" et "char *"

Ou plus exactement en C, on a:

• Conversion implicite entre "abc" et char*, pour cette histoire de compatibilit� (sous gcc, on peut d�sactiver �a avec l'option -Wwrite-strings en ligne de commande).
• Conversion implicite autoris�e mais (le plus souvent) avec warning de X const* � X*, du au typage faible du C.