Bonjour, je m'initie =E0 la notion de pointeurs, et un truc m'obs=E8de
et je n'obtiens pas de r=E9ponse.=20
Quand on cr=E9er par exemple un pointeur d'entier : int *x, =E0 ce
moment, &x donne la r=E9f=E9rence m=E9moire, =E7a c'est ok.=20
*x d=E9signe alors le contenu de cette adresse m=E9moire, c'est ok =
aussi.
Mais =E0 quoi correspond la valeur de x ?
Lorsque j'affiche &x, j'obtiens 0x22ff74
Lorsque j'affiche x, j'obtiens 0x2
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton programme), soit tu obtiendras une valeur bidon.
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Enfin, un truc qui peut être utile, et qui ne fait pas planter le programme :
int n= 42; int *p= &n; cout << &n << "n"; // Affiche l'adresse en mémoire de n cout << p << "n"; // Affiche la même chose cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n. => p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n. => *p == n
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut
pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire
auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet
endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton
programme), soit tu obtiendras une valeur bidon.
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.
Enfin, un truc qui peut être utile, et qui ne fait pas planter le
programme :
int n= 42;
int *p= &n;
cout << &n << "n"; // Affiche l'adresse en mémoire de n
cout << p << "n"; // Affiche la même chose
cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n.
=> p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n.
=> *p == n
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton programme), soit tu obtiendras une valeur bidon.
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Enfin, un truc qui peut être utile, et qui ne fait pas planter le programme :
int n= 42; int *p= &n; cout << &n << "n"; // Affiche l'adresse en mémoire de n cout << p << "n"; // Affiche la même chose cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n. => p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n. => *p == n
Zarak
"Fabien LE LEZ" a écrit dans le message de news:
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
Si oui, dans ce cas je formulerais comme ça : Après un int* x (oublions le fait que ce soit pas initialisé), x == adresse mémoire &x == adresse mémoire de l'adresse mémoire ci-dessus *x == valeur contenue dans l'adresse mémoire
J'ai bon ou c'est tout faux ? :)
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news: 75uv85pkei8ctjbp83klr6cr2e0p3e4j1m@4ax.com...
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
Si oui, dans ce cas je formulerais comme ça :
Après un int* x (oublions le fait que ce soit pas initialisé),
x == adresse mémoire
&x == adresse mémoire de l'adresse mémoire ci-dessus
*x == valeur contenue dans l'adresse mémoire
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
Si oui, dans ce cas je formulerais comme ça : Après un int* x (oublions le fait que ce soit pas initialisé), x == adresse mémoire &x == adresse mémoire de l'adresse mémoire ci-dessus *x == valeur contenue dans l'adresse mémoire
J'ai bon ou c'est tout faux ? :)
Fabien LE LEZ
On Sat, 22 Aug 2009 16:10:04 +0200, "Zarak" <zarakonline AT free.fr>:
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
En gros, oui.
J'ai bon
Oui.
On Sat, 22 Aug 2009 16:10:04 +0200, "Zarak" <zarakonline AT free.fr>:
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
On Sat, 22 Aug 2009 16:10:04 +0200, "Zarak" <zarakonline AT free.fr>:
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?
En gros, oui.
J'ai bon
Oui.
Ok, merci.
pjb
Fabien LE LEZ writes:
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton programme), soit tu obtiendras une valeur bidon.
Ou pire, ça peut geler la machine. N'importe quoi peut vraiment arriver. (Malheureusement, le langage n'impose pas aux compilateurs de marquer les variables non initialisées et de générer une erreur lorsqu'on les utilise).
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Enfin, un truc qui peut être utile, et qui ne fait pas planter le programme :
int n= 42; int *p= &n; cout << &n << "n"; // Affiche l'adresse en mémoire de n cout << p << "n"; // Affiche la même chose cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n. => p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n. => *p == n
On peut se servir de ce truc pour faire des pointeurs qui ne peuvent jamais être null, donc que l'on puisse toujours déréférencer. Bien encapsulé dans un template, ça peut être utile...
-- __Pascal Bourguignon__
Fabien LE LEZ <gramster@gramster.com> writes:
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut
pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire
auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet
endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton
programme), soit tu obtiendras une valeur bidon.
Ou pire, ça peut geler la machine. N'importe quoi peut vraiment
arriver. (Malheureusement, le langage n'impose pas aux compilateurs
de marquer les variables non initialisées et de générer une erreur
lorsqu'on les utilise).
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).
Enfin, un truc qui peut être utile, et qui ne fait pas planter le
programme :
int n= 42;
int *p= &n;
cout << &n << "n"; // Affiche l'adresse en mémoire de n
cout << p << "n"; // Affiche la même chose
cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n.
=> p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n.
=> *p == n
On peut se servir de ce truc pour faire des pointeurs qui ne peuvent
jamais être null, donc que l'on puisse toujours déréférencer. Bien
encapsulé dans un template, ça peut être utile...
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak" <zarakonline AT free.fr>:
Quand on créer par exemple un pointeur d'entier : int *x, à ce moment, &x donne la référence mémoire, ça c'est ok.
Attention, &x est un pointeur sur ton pointeur.
Lorsque j'affiche x, j'obtiens 0x2
A quoi correspond exactement ce 0x2 ?
Si tu écris :
int *p;
ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire auquel ton programme n'a pas accès.
Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet endroit. Ça n'a pas vraiment de sens.
Typiquement, sur un PC, soit l'OS va râler (et terminer ton programme), soit tu obtiendras une valeur bidon.
Ou pire, ça peut geler la machine. N'importe quoi peut vraiment arriver. (Malheureusement, le langage n'impose pas aux compilateurs de marquer les variables non initialisées et de générer une erreur lorsqu'on les utilise).
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Enfin, un truc qui peut être utile, et qui ne fait pas planter le programme :
int n= 42; int *p= &n; cout << &n << "n"; // Affiche l'adresse en mémoire de n cout << p << "n"; // Affiche la même chose cout << *p << "n"; // Affiche la valeur de n, soit 42.
p est un pointeur sur n, i.e. (grosso modo) l'adresse de n. => p == &n
*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n. => *p == n
On peut se servir de ce truc pour faire des pointeurs qui ne peuvent jamais être null, donc que l'on puisse toujours déréférencer. Bien encapsulé dans un template, ça peut être utile...
-- __Pascal Bourguignon__
espie
In article , Pascal J. Bourguignon wrote:
Fabien LE LEZ writes:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
In article <7cljl9wo7q.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Marc Boyer
Le 24-08-2009, Marc Espie a écrit :
In article , Pascal J. Bourguignon wrote:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 24-08-2009, Marc Espie <espie@lain.home> a écrit :
In article <7cljl9wo7q.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Jean-Marc Bourguet
Marc Boyer writes:
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un > pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais pas MacOS et ne me prononce pas sur le fond de l'histoire).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
> pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais
pas MacOS et ne me prononce pas sur le fond de l'histoire).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un > pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais pas MacOS et ne me prononce pas sur le fond de l'histoire).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Le 24-08-2009, Jean-Marc Bourguet a écrit :
Marc Boyer writes:
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un > pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais pas MacOS et ne me prononce pas sur le fond de l'histoire).
Ca dépend de la définition de bug, en effet. "It's not a bug, it's a feature"...
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 24-08-2009, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
> pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais
pas MacOS et ne me prononce pas sur le fond de l'histoire).
Ca dépend de la définition de bug, en effet.
"It's not a bug, it's a feature"...
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un > pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Un comportement peut etre conforme tout en etant un bug. (Je ne connais pas MacOS et ne me prononce pas sur le fond de l'histoire).
Ca dépend de la définition de bug, en effet. "It's not a bug, it's a feature"...
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Wykaaa
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie a écrit :
In article , Pascal J. Bourguignon wrote:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
J'ai implémenter un compilateur C sur une machine où l'adresse 0 était valide (c'était même l'adresse du segment résident du système...). Evidemment, nous avons remplacé 0 par une valeur invalide sur notre machine (en l'occurence -1 : FFFFFFFF). Sur une affectation de pointeur à NULL ou une comparaison, il fallait évidemment remplacer par -1 mais c'était transparent pour le programmeur (mais quelle cuisine !).
En C++, dans l'annotated reference manual, il est dit, en haut de la page 36 : "Note that the null pointer need not be represented by the same bit pattern as the integer 0". Stroustrup, en effet, s'était rendu compte que la valeur 0, pour le pointeur null en C, posait des problèmes sur certaines machines.
Dans le Working Draft, Standard for Programming Language C++ (4 octobre 2008), il est dit (§ 1.9- 4) : Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer). [ Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. —end note ]
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Je ne pense pas.
Marc Boyer
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie <espie@lain.home> a écrit :
In article <7cljl9wo7q.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Ceci a un petit peu plus de sens :
int *p= 0;
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.
J'ai implémenter un compilateur C sur une machine où l'adresse 0 était
valide (c'était même l'adresse du segment résident du système...).
Evidemment, nous avons remplacé 0 par une valeur invalide sur notre
machine (en l'occurence -1 : FFFFFFFF). Sur une affectation de pointeur
à NULL ou une comparaison, il fallait évidemment remplacer par -1 mais
c'était transparent pour le programmeur (mais quelle cuisine !).
En C++, dans l'annotated reference manual, il est dit, en haut de la
page 36 :
"Note that the null pointer need not be represented by the same bit
pattern as the integer 0".
Stroustrup, en effet, s'était rendu compte que la valeur 0, pour le
pointeur null en C, posait des problèmes sur certaines machines.
Dans le Working Draft, Standard for Programming Language C++ (4 octobre
2008), il est dit (§ 1.9- 4) :
Certain other operations are described in this International Standard as
undefined (for example, the effect of dereferencing the null pointer).
[ Note: this International Standard imposes no requirements on the
behavior of programs that contain undefined behavior. —end note ]
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude : le programme s'arrête immédiatement.
Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une valeur.
(Malheureusement, le langage n'impose pas aux compilateurs de générer une erreur lorsqu'on déréférence un pointeur null).
Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un pointeur nul, qui doit etre invalide.
De mémoire, déréferencer le pointeur null, c'est juste un "undefined behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut être accessible.
J'ai implémenter un compilateur C sur une machine où l'adresse 0 était valide (c'était même l'adresse du segment résident du système...). Evidemment, nous avons remplacé 0 par une valeur invalide sur notre machine (en l'occurence -1 : FFFFFFFF). Sur une affectation de pointeur à NULL ou une comparaison, il fallait évidemment remplacer par -1 mais c'était transparent pour le programmeur (mais quelle cuisine !).
En C++, dans l'annotated reference manual, il est dit, en haut de la page 36 : "Note that the null pointer need not be represented by the same bit pattern as the integer 0". Stroustrup, en effet, s'était rendu compte que la valeur 0, pour le pointeur null en C, posait des problèmes sur certaines machines.
Dans le Working Draft, Standard for Programming Language C++ (4 octobre 2008), il est dit (§ 1.9- 4) : Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer). [ Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. —end note ]
Mais si tu as un passage de la norme qui dit que ça *doit* provoquer une erreur, je m'incline.
D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.
Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
