Taille d'un pointeur NULL

Bonsoir,

Je me posais une petite question, est-ce qu'un pointeur sur NULL prend une quelconque place en mémoire, ou alors strictement rien du tout ?

Merci

ça veut rien dire... un pointeur pointe sur une zone mémoire, ce qui prend de la place c'est la zone allouée, pas le pointeur. Que tu le fasse pointer vers NULL ou une zone réellement allouée, ça change rien.

Ouais le pointeur n'occupera pas plus ou moins d'espace si tu changes la variable pointée. L'espace occupé correspond à l'espace requis pour identifier une adresse mémoire.

Tu peux connaître la taille d'un pointeur grâce à un sizeof.
J'obtiens une taille de 32 bits quelque soit la variable pointée.

Tu peux faire le test grâce à ce programme:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <iostream> using namespace std;   int main() { int* pointeur = NULL; cout << "pointeur = NULL: " << sizeof(pointeur)*8 << "bits" << endl;   int a=3; pointeur = &a; cout << "pointeur = &a: " << sizeof(pointeur)*8 << "bits" << endl;   double b = 5.56; double* pointeur2 = &b; cout << "pointeur sur double: " << sizeof(pointeur2)*8 << "bits" << endl;   return 0; }

---

Et j'obtiens:

Code:

---

1 2 3

pointeur = NULL: 32bits pointeur = &a: 32bits pointeur sur double: 32bits

---

Ok merci :).

Citation:

---

Envoyé par BoudBoulMan

Tu peux faire le test grâce à ce programme:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <iostream> using namespace std;   int main() { int* pointeur = NULL; cout << "pointeur = NULL: " << sizeof(pointeur)*8 << "bits" << endl;   int a=3; pointeur = &a; cout << "pointeur = &a: " << sizeof(pointeur)*8 << "bits" << endl;   double b = 5.56; double* pointeur2 = &b; cout << "pointeur sur double: " << sizeof(pointeur2)*8 << "bits" << endl;   return 0; }

---

---

sizeof est une constante de compilation, qui ne dépend pas de la valeur de son argument, juste de son type. En fait l'argument de sizeof n'est pas évalué. On peut donc faire sizeof une variable non-initialisée (très courant) :

Code:

---

1 2 3

int i; cout << i ; // NON! comportement indéfini! cout << sizeof i; // OK

---

On pourrait même faire des choses "interdites" dans sizeof :

Code:

---

cout << sizeof (*(int*)0); // équivaut à sizeof (int)

---

Et c'est d'ailleurs parce qu'il est évalué à la compilation qu'on le retrouve souvent dans des techniques de métaprogrammation.

Excusez moi de changer de sujet mais :

Code:

---

cout << i ; // NON! comportement indéfini!

---

?

Pourquoi?

Citation:

---

Envoyé par Klaim

Code:

---

cout << i ; // NON! comportement indéfini!

---

---

Ici i n'est pas initialisé.

Lire une variable (d'un type de base) non initialisée donne un comportement indéfini, par exemple :

Code:

---

1 2	int i, j; i = j; // comportement indéfini : j n'est pas initialisé

---

Un pointeur qui a été désalloué ne peut plus être examiné non plus :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int *p = new int; cout << p; // OK, imprime l'adresse de l'entier cout << *p; // comportement indéfini : l'entier n'as pas de valeur *p = 1; cout << *p; // OK, imprime 1 int *q = p; // pas de pb delete p; // pas de pb // à partir de là, p ne contient plus une adresse valide cout << p; // comportement indéfini : lecture de p cout << q; // comportement indéfini : q n'est plus valide cout << p == q ? "égal" : "différent"; // comportement indéfini p = new int; // pas de pb q = p; cout << p == q ? "égal" : "différent"; // imprime égal

---

Même sans utiliser delete, on peut avoir le cas : soit un pointeur vers une variable dont la durée de vie est terminée :

Code:

---

1 2 3 4 5 6 7

int *p; { int i; p = &i; cout << p; // imprime l'adresse de i } // fin de la portée de i, fin de la durée de vie de i cout << p; // comportement indéfini : i n'existe plus

---

Les seules choses qu'on peut faire avec une variable primitive non-initialisée, un pointer désalloué (avec free, delete, etc.), ou un pointeur contenait l'adresse d'une variable dont la durée de vie est terminée :

• le "détruire" (terminer sa durée de vie, ce qui ne fait rien, les scalaires ont des destructeurs triviaux)
• lui affecter une nouvelle valeur

(unsigned char est particulier et échappe à la règle.)

Dites-moi si je me trompe mais, si on ne voit pas vraiment le comportement indéfini que pourrait provoquer le cout << d'un entier non initialisé (simple valeur non prédictible), on comprend mieux avec le simple cout << d'un pointeur non initialisé et déréférencé. Or le principe est bien le même : l'utilisation d'une variable T non initialisée.
Maintenant, ce n'est peut-être pas ce que dis vraiment la norme, je ne l'ai pas lue.

Citation:

---

(unsigned char est particulier et échappe à la règle.)

---

C'eut été intéressant de nous dire en quoi. :)

Citation:

---

Envoyé par corrector

Code:

---

1 2 3

cout << p; // comportement indéfini : lecture de p cout << q; // comportement indéfini : q n'est plus valide cout << p == q ? "égal" : "différent"; // comportement indéfini

---

---

Euh, là, je me permets de douter: Où est le problème tant qu'on ne déréférence pas le pointeur ?
Est-il justement dans l'absence de garantie que le pointeur ne sera pas déréférencé ?

Citation:

---

Lire une variable (d'un type de base) non initialisée donne un comportement indéfini, par exemple :

---

Faux !
Lire cette valeur est totalement défini. C'est la valeure qui est totalement hasardeuse.

Citation:

---

Lire cette valeur est totalement défini. C'est la valeure qui est totalement hasardeuse

---

Cela doit surement dépendre de l'espace de travail utilisé en tout cas pour Visual Studio 2005 voilà les résultats pour :

Code:

---

1 2	int i, j; i = j;

---

En mode debug :

Citation:

---

Run-Time Check Failure #3 - The variable 'j' is being used without being initialized.

---

Et idem pour i bien sur, l'assertion permet cependant de continuer, les variables sont par défaut à -858993460.
En mode release, les variables sont simplement initialisées à 0...

C'est plutôt intéressant comme résultat... (je ne dit surtout pas qu'il faut le faire:aie:) mais quelle serait le comportement d'un telle code, cela dépend-t-il vraiment du compilateur et donc "pourrait" produire un code(/application) "stable" ou non? (Simple curiosité :mrgreen:)

En debug la pile est marqée par le code hexa #CC pour que les pointeurs pointent dans la moquette. En debug tu verras donc souvent des acces a #CCCCCCD0 qui est juste un offset de #CCCCCCCC

en release la variable n'est _pas initialisée_ du tout. si tu recois 0 c'est que la precedente variable qui etait a cet endroit avait decidé d'y mettre 0. si elle avait decidé d'y mettre 72 tu etais fichu.

Cela a par contre effet assez ennuyeux, c'est que les booleens sont toujours initialisé a #CC donc "true", et cela peut faire marcher un truc en debug mais pas en release. Quand je lis "ca marche en debug mais pas en release" je pense immediatement a une initialisation du mode debug (la pile, le tas) qui aurait mis un booleen a true, et je recommande de verifier l'initialisation des booléens. 3 fois ou cela c'est produit (avec comme seul diagnostique "ca marche en debug mais pas en release") et 3 fois la reponse etait un booléen initialisé comme un pied.

Citation:

---

Envoyé par NiamorH

Dites-moi si je me trompe mais, si on ne voit pas vraiment le comportement indéfini que pourrait provoquer

---

Je crois que tu ne saisis pas exactement le concept de comportement indéfini : c'est juste ce qui n'est pas défini! Ce n'est pas un comportement précis.

La norme ne place aucune exigence sur l'implémentation concernant ce code.

Le programme peut faire n'importe quoi, le compilateur sera toujours conforme.

Citation:

---

Envoyé par NiamorH

Maintenant, ce n'est peut-être pas ce que dis vraiment la norme, je ne l'ai pas lue.

---

La norme décrit la conversion de lvalue en rvalue :

Citation:

---

Envoyé par draft C++, 4.1/1

An lvalue (3.10) of a non-function, non-array type T can be converted to an rvalue. [...] If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.

---

(Ce n'est pas bien formulé d'ailleurs : il faut lire "or if T is a non-class type, and T is not char or unsigned char, and if the object is uninitialized, ...". Parce que là...)

Citation:

---

Envoyé par NiamorH

C'eut été intéressant de nous dire en quoi. :)

---

En gros tu peux les lire, mais la valeur n'est pas définie, et elle n'est même pas garantie d'être deux fois la même :

Code:

---

1 2 3 4

unsigned char c; // ou char cout << (int)c; // affiche un nombre entre 0 et UCHAR_MAX cout << (int)c; // affiche encore un nombre entre 0 et UCHAR_MAX, pas forcément le même cout << c == c ? "OK" : "étrange"; // affiche soit OK soit étrange

---

Ceci dit, ça n'est écrit clairement nul part. C'est une inférence à partir de la norme et aussi "common wisdom". J'aurai du mal à le justifier formellement. :oops: (La norme n'est vraiment pas assez formalisée.)

Citation:

---

Envoyé par Davidbrcz

Faux !
Lire cette valeur est totalement défini. C'est la valeure qui est totalement hasardeuse.

---

D'accord, mais alors, défini où ça?

(Chapitre et paragraphe s'il te plait.)

Citation:

---

Envoyé par Médinoc

Euh, là, je me permets de douter: Où est le problème tant qu'on ne déréférence pas le pointeur ?

---

La valeur du pointeur ne doit plus être utilisée. Comme s'il était non-initialisé. Tu ne peux même pas recopier la valeur.

Citation:

---

Envoyé par C++ draft, 3.7.3.2/4 [basic.stc.dynamic.deallocation]

If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, rendering invalid all pointers referring to any part of the deallocated storage.

---

Citation:

---

Envoyé par Médinoc

Est-il justement dans l'absence de garantie que le pointeur ne sera pas déréférencé ?

---

Non, copier, ou afficher un pointeur ne le déréférence pas, encore heureux. :lol:

Citation:

---

Envoyé par corrector

D'accord, mais alors, défini où ça?

(Chapitre et paragraphe s'il te plait.)

---

Je n'ai plus le standard en tête, mais je suis sûr de moi.

Imagine le code suivant :

Code:

---

1 2 3

int a; cout<<a;

---

La 1er ligne créer une variable sur la pile sans lui affecté de valeur.
Elle prend donc la valeur de ce qui se trouvait avant à cette place.
Il n'y a pas de moyen de connaitre cette valeur. C'est dans ce sens que je dis que la valeur est indéfinie.

Par contre la 2eme ligne, elle a un comportement totalement défini.Elle va t'afficher la valeur de a, qui peut être n'importe quoi.

Oui, le cout est tout à fait défini.

Pour preuve, effectue-la deux fois, et tu obtiendras le même résultat.

Code:

---

1 2 3

int a; cout << a << endl; cout << a << endl; // affiche deux fois la même valeur

---

Citation:

---

Envoyé par Davidbrcz

Je n'ai plus le standard en tête, mais je suis sûr de moi.

---

Moi si, lis mon autre réponse.

Citation:

---

Envoyé par Davidbrcz

Imagine le code suivant :

Code:

---

1 2 3

int a; cout<<a;

---

La 1er ligne créer une variable sur la pile sans lui affecté de valeur.
Elle prend donc la valeur de ce qui se trouvait avant à cette place.

---

C'est un comportement observable possible. Ce n'est pas le seul.

Citation:

---

Envoyé par Davidbrcz

Il n'y a pas de moyen de connaitre cette valeur. C'est dans ce sens que je dis que la valeur est indéfinie.

---

Sur certains systèmes, les entiers signés ne sont pas représentés en complément à 2 mais en complément à 1 ou en signe-magnitude. Parfois en signe-magnitude on considère que l'entier représentant 0 doit avoir un signe positif (signe 0). Si un entier représentant 0 a un signe négatif (représentation binaire un 1 suivit de zéros), c'est une erreur, et le processeur déclenche une exception. Si tu es sur un tel système, a peut avoir ce que la norme C appelle une "trap representation", un motif de bits qui n'a pas de sens pour le type de la variable. Tenter d'accèder à la valeur de la variable va alors déclencher une trap, une exception processeur. Qui peut se traduire par un signal et terminer brutalement (abort) le programme.

Sur ce système, selon ce qui se trouvait avant à l'adresse de a, le programme peut planter ou pas. Ce qui est un autre exemple de comportement observable.

Ces différents comportements sont permis par la norme puisque elle ne défini rien à propos du comportement d'un programme qui accède à une variable non initialisée. Ce qu'on appelle donc un comportement indéfini.

Citation:

---

Envoyé par Davidbrcz

Par contre la 2eme ligne, elle a un comportement totalement défini.Elle va t'afficher la valeur de a, qui peut être n'importe quoi.

---

Formellement (selon la sémantique définie par la norme C++), a n'a pas de valeur.

Avant qu'on lui affecte une valeur, le compilateur n'est même pas obligé de lui allouer un emplacement rien qu'à elle dans la pile (ou un registre rien qu'à elle).

Citation:

---

Envoyé par BoudBoulMan

Oui, le cout est tout à fait défini.

---

NON.

Citation:

---

Envoyé par BoudBoulMan

Pour preuve, effectue-la deux fois, et tu obtiendras le même résultat.

Code:

---

1 2 3

int a; cout << a << endl; cout << a << endl; // affiche deux fois la même valeur

---

---

Qu'est-ce que c'est censé prouver? Encore une fois : le comportement N'EST PAS défini. J'ai déjà cité la norme. J'ai déjà expliqué ce que cela signifiait.

De plus, babar63 a donné un exemple de comportement très sympathique qui ne correspond pas à ce que tu dis.

Je me demande si certains savent lire. :evilred: Ou alors ils croient que leur expérience personnelle (limitée, forcément limité) leur donne la connaissance absolue.

PS : tester (une, plusieurs, un million de fois) un programme ne garantit qu'il est correct. Par contre un test qui échoue démontre qu'il est bugué.

Citation:

---

Envoyé par corrector

le comportement N'EST PAS défini.

---

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

Citation:

---

Envoyé par BoudBoulMan

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

---

Possible, selon http://www.developpez.net/forums/sho...7&postcount=19

Thierry

comme cité par corrector

Code:

---

1 2 3 4 5 6 7 8

#include <iostream>   int main() { int a; std::cout << a; return 0; }

---

sur visual studio 2005 en debug va t'afficher une boite de dialogue. Sous GCC, cela va afficher un truc (personne ne peut vraiment predire quoi).

Le comportement est donc indefini. CQFD.

Vous pensez que c'est defini car vous pensez que le compilateur va allouer de la place sur la pile, puis que vous allez afficher cette place sur la pile.

Pensez que je pourrais faire un compilateur qui n'alloue pas sur la pile, mais alloue a la demande de la memoire dynamique pour chaque variable. Comme c'est fait sur demande, tant que je ne fais rien je n'alloue pas. Du coup, lorsque je lis cette valeur je n'ai pas encore alloué de l'espace et ca va planter.

lire une valeur non initialisée est indefini, en general ca renvoie une valeur aleatoire (enfin, disons plutot determinée par laposition de saturne et l'age du capitaine, c'est a dire que avec deux executions la valeur sera sans doute identique) mais ce n'est pas la seule implementation possible, et visual studio ajoute une boite de dialogue qui pete a la figure a l'execution.

Citation:

---

Envoyé par Médinoc

Euh, là, je me permets de douter: Où est le problème tant qu'on ne déréférence pas le pointeur ?

---

Il y a des cas où simplement accéder à un pointeur invalide (sans tenter de lire la zone pointée) peut poser un problème. Par exemple, charger un descripteur de segment invalide génère une exception sur un x86.

Citation:

---

Envoyé par corrector

(Ce n'est pas bien formulé d'ailleurs : il faut lire "or if T is a non-class type, and T is not char or unsigned char, and if the object is uninitialized, ...". Parce que là...)

---

char peut avoir des trap value... unsigned char non.

Citation:

---

Envoyé par BoudBoulMan

En quoi le comportement de cout n'est pas défini? Il va faire autre chose qu'afficher la valeur de a?

---

Le problème est que la valeur de a n'est pas définie. Et ce qui se trouve par hasard en mémoire peut ne pas être une valeur acceptable. Par exemple il y a eu des machines à tag où chaque mot mémoire avait un tag décrivant son type. Sans initialisation, celui-ci peut être incorrect. Autre exemple, il y a eu une machine qui n'avait comme représentation numérique qu'une représentation flottante mais qui avait des instructions qui trappaient si une valeur n'était pas entière.

Citation:

---

Envoyé par Jean-Marc.Bourguet

char peut avoir des trap value... unsigned char non.

---

Je ne pense pas que ça puisse être compatible avec ceci :

Citation:

---

Envoyé par C++ draft N2315, 3.10/15 [basic.lval]

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined
[...]
— a char or unsigned char type.

---

ce qui suggère une contradiction avec la clause de non-initialisation.

Cette clause est vraiment troublante, car elle suggère de faire des choses que rien n'autorise; en effet, comment obtenir les lvalues suivantes :

Citation:

---

Envoyé par C++ draft N2315, 3.10/15 [basic.lval]

— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a char or unsigned char type.

---

alors que

Citation:

---

Envoyé par C++ draft N2315, 5.2.10/7 [expr.reinterpret.cast]

A pointer to an object can be explicitly converted to a pointer to an object of different type. [...] the result of such a pointer conversion is unspecified.

---

Dans ce cas, quel intérêt de nous raconter ça :

Citation:

---

Envoyé par C++ draft N2315, 3.9.1/3 [basic.fundamental]

For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer
type: “unsigned char”, “unsigned short int”, “unsigned int”, “unsigned long int”, and “unsigned long long int”, each of which occupies the same amount of storage and has the same alignment requirements (3.9) as the corresponding signed integer type; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. [...] the value representation of each corresponding signed/unsigned type shall be the same.

---

Encore une phrase qui ne veut rien dire : comment un type signé pourrait avoir la même représentation qu'un type non-signé? En fait, il faut lire quelque chose comme :

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of values in such range shall be the same in both types.

(Zut, moi qui voulais faire une réponse courte.)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Autre exemple, il y a eu une machine qui n'avait comme représentation numérique qu'une représentation flottante mais qui avait des instructions qui trappaient si une valeur n'était pas entière.

---

Tient, c'est rigolo comme architecture.

Citation:

---

Envoyé par BoudBoulMan

En quoi le comportement de cout n'est pas défini?

---

Où est-il défini?

Citation:

---

Envoyé par BoudBoulMan

Il va faire autre chose qu'afficher la valeur de a?

---

Potentiellement, reformater ton disque dur ou démarrer une partie de nethack.

En pratique, c'est vrai qu'il y a moins de risques qu'avec le déréférencement d'un pointeur non initialisé. Mais une variable non initialisée n'est pas juste une variable qui a une valeur inconnue.

Citation:

---

Envoyé par corrector

Je ne pense pas que ça puisse être compatible avec ceci :

---

Ce n'est pas une enumeration de tous les cas de comportements indefini, mais de comportement qui sont a coup sur indefini. Subtile difference.

Je ne sais pas si ca a change depuis et je n'ai pas le temps de faire une recherche, mais la norme de 98 dit en 3.9.1/1 que char peut etre la meme chose que signed char, et que seul unsigned char est garanti avoir tous les bit patterns comme valeurs acceptables (cas du complement a 1...) meme si on est sur de ne pas avoir de bits ne participant pas a la valeur pour tous les types caracteres.

Si char etait enleve de ta citation, le comportement aurait ete rendu indefini meme dans les implementations pour lesquelles char equivaut a unsigned char. Tel que redige, le comportement est indefini uniquement pour celles ou char equivaut a signed char.

C'est la grosse difficulte de la lecture de la norme, il faut non seulement trouver une description, il faut aussi etre raisonablement sur que ce n'est pas modifie a d'autres endroits.

Pour le reste, j'ai des choses a repondre mais ca attendra que je puisse retrouver les citations adequates.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ce n'est pas une enumeration de tous les cas de comportements indefini, mais de comportement qui sont a coup sur indefini. Subtile difference.

---

Formellement, oui. Mais pourquoi spécifier que le comportement est indéfini alors qu'il l'est déjà? (Pourquoi cette clause?)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je ne sais pas si ca a change depuis et je n'ai pas le temps de faire une recherche, mais la norme de 98 dit en 3.9.1/1 que char peut etre la meme chose que signed char, et que seul unsigned char est garanti avoir tous les bit patterns comme valeurs acceptables (cas du complement a 1...) meme si on est sur de ne pas avoir de bits ne participant pas a la valeur pour tous les types caracteres.

---

Pas de changement :

Citation:

---

Envoyé par C++ draft N2315, 3.9.1/1

For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types.

---

Je n'avais pas vu ça.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si char etait enleve de ta citation, le comportement aurait ete rendu indefini meme dans les implementations pour lesquelles char equivaut a unsigned char. Tel que redige, le comportement est indefini uniquement pour celles ou char equivaut a signed char.

---

Oula!

Plus précisément : le comportement est indéfini pour les implémentations où CHAR_MAX - CHAR_MIN != UCHAR_MAX. Mais la norme C++ ne parle pas de "trap representation". Formellement, elle ne dit pas explicitement que c'est indéfini.

Citation:

---

Envoyé par Jean-Marc.Bourguet

C'est la grosse difficulte de la lecture de la norme, il faut non seulement trouver une description, il faut aussi etre raisonablement sur que ce n'est pas modifie a d'autres endroits.

---

C'est pas de la tarte!

O___O;

Merci pour les détails!
Une erreur d'attention de ma part (je n'ai pas vu l'ascence d'initialization de i dans l'exemple) aura mis en avant une obscure subtilitée du language :aie: