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.