Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[débutant] Pointeurs

20 réponses
Avatar
Zarak
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

A quoi correspond exactement ce 0x2 ?

Merci beaucoup.

10 réponses

1 2
Avatar
espie
In article <4a92937d$0$23477$,
Wykaaa wrote:
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie a écrit :
In article ,
Pascal J. Bourguignon wrote:



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.





On va exprimer ca autrement: une implementation qui autorise les
dereferencements du pointeur nul et qui ne provoque pas une belle erreur a
ce moment-la est une implementation de merde. En particulier, au niveau
securite (deja que les buffer overflow ca s'exploite, et les pointeurs nuls
sur des structures egalement... alors si en plus ca marche tout seul et qu'il
n'y a meme pas besoin de ruser, c'est vraiment mauvais).

Sur les systemes "specifiques" embarques, et autres, c'est deja mauvais de
perdre ce genre de diagnostic. Sur un systeme qui se veut generaliste, on
se demande franchement dans quel placard vivent les guignols qui ont voulu
pondre ce systeme...

Apres, que ca soit dans la norme ou pas. C'est un item "quality of
implementation"... avec une note tres mauvaise (style 0/20) pour les
implementations qui permettent ca...
Avatar
Marc Boyer
Le 24-08-2009, Marc Espie a écrit :
In article <4a92937d$0$23477$,
Wykaaa wrote:
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie a écrit :
In article ,
Pascal J. Bourguignon wrote:



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.





On va exprimer ca autrement: une implementation qui autorise les
dereferencements du pointeur nul et qui ne provoque pas une belle erreur a
ce moment-la est une implementation de merde.



Tout à fait d'accord.

Sur les systemes "specifiques" embarques, et autres, c'est deja mauvais de
perdre ce genre de diagnostic. Sur un systeme qui se veut generaliste, on
se demande franchement dans quel placard vivent les guignols qui ont voulu
pondre ce systeme...



On attaque qui là, l'OS ou le compilo C ?

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
Avatar
espie
In article <h6u7ku$j5o$,
Marc Boyer wrote:
Le 24-08-2009, Marc Espie a écrit :
In article <4a92937d$0$23477$,
Wykaaa wrote:
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie a écrit :
In article ,
Pascal J. Bourguignon wrote:



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.





On va exprimer ca autrement: une implementation qui autorise les
dereferencements du pointeur nul et qui ne provoque pas une belle erreur a
ce moment-la est une implementation de merde.



Tout à fait d'accord.

Sur les systemes "specifiques" embarques, et autres, c'est deja mauvais de
perdre ce genre de diagnostic. Sur un systeme qui se veut generaliste, on
se demande franchement dans quel placard vivent les guignols qui ont voulu
pondre ce systeme...



On attaque qui là, l'OS ou le compilo C ?

Marc Boyer



Sans doute les deux. Une implementation, c'est un ensemble. Ca fait, ouhla,
pas mal d'annees qu'on sait que permettre de dereferencer l'adresse 0 en mode
utilisateur, c'est une enorme connerie. Et Wykaa a rappele que ca n'est pas
tres dur de prevoir autre chose comme representation du pointeur nul si
necessaire...
Avatar
pjb
(Marc Espie) writes:

In article <4a92937d$0$23477$,
Wykaaa wrote:
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie a écrit :
In article ,
Pascal J. Bourguignon wrote:



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.





On va exprimer ca autrement: une implementation qui autorise les
dereferencements du pointeur nul et qui ne provoque pas une belle erreur a
ce moment-la est une implementation de merde. En particulier, au niveau
securite (deja que les buffer overflow ca s'exploite, et les pointeurs nuls
sur des structures egalement... alors si en plus ca marche tout seul et qu'il
n'y a meme pas besoin de ruser, c'est vraiment mauvais).

Sur les systemes "specifiques" embarques, et autres, c'est deja mauvais de
perdre ce genre de diagnostic. Sur un systeme qui se veut generaliste, on
se demande franchement dans quel placard vivent les guignols qui ont voulu
pondre ce systeme...



Dans un petit placard, dans lequel il n'y a pas C, et à l'époque où
C++ n'existe pas encore. On programmait soit en assembleur (et alors
de toutes façons on n'a qu'à bien se tenir) ou en Pascal, et alors le
compilateur se charge de tester les pointeurs nuls.
C'était le bon temps ! :-)


Apres, que ca soit dans la norme ou pas. C'est un item "quality of
implementation"... avec une note tres mauvaise (style 0/20) pour les
implementations qui permettent ca...



Oui.

--
__Pascal Bourguignon__
Avatar
James Kanze
On Aug 24, 2:02 pm, (Marc Espie) wrote:
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.



Non. D'abord, ce que la norme exige, ce n'est pas que un
pointeur nul soit un pointeur invalide (ce qui n'a pas de sens
sur certains ordinateurs), mais simplement qu'il ait une valeur
qui ne correspond pas à l'adresse d'un objet (C++). Sur les
anciens PC (sous MS-DOS), écrire avec un pointeur nul modifier
la table des interruptions, et sur les premiers Unix, on mettait
le premier 510 octets de l'espace d'adressage à 0, de façon que
lire à travers un pointeur null donnait toujours 0 (et beaucoup
d'utilitaire s'en servait). Selon la norme, c'est un
comportement indéfini, et si comme dit Pascal, la norme n'exige
aucune vérification, elle ne l'interdit pas non plus.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Aug 24, 3:49 pm, (Marc Espie) wrote:
In article <4a92937d$0$23477$,



Wykaaa wrote:
>Marc Boyer a écrit :
>> Le 24-08-2009, Marc Espie a écrit :
>>> In article ,
>>> Pascal J. Bourguignon wrote:



>> 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.



On va exprimer ca autrement: une implementation qui autorise
les dereferencements du pointeur nul et qui ne provoque pas
une belle erreur a ce moment-la est une implementation de
merde. En particulier, au niveau securite (deja que les buffer
overflow ca s'exploite, et les pointeurs nuls sur des
structures egalement... alors si en plus ca marche tout seul
et qu'il n'y a meme pas besoin de ruser, c'est vraiment
mauvais).



Ça dépend du contexte, je crois. Pour une implémenatation sur
une machine généraliste, genre PC ou station de travail, avec
des MMU et tout, je suis d'accord avec toi. Mais je me suis
servi aussi de C sur des PC 8 bits, avec un maximum de 64 Ko de
mémoire, et pas de protection du tout; détecter un accès à
travers un pointeur nul y exigerait beaucoup de code en plus, et
la mémoire est déjà ultra-serrée.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
espie
In article ,
James Kanze wrote:
Ça dépend du contexte, je crois. Pour une implémenatation sur
une machine généraliste, genre PC ou station de travail, avec
des MMU et tout, je suis d'accord avec toi. Mais je me suis
servi aussi de C sur des PC 8 bits, avec un maximum de 64 Ko de
mémoire, et pas de protection du tout; détecter un accès à
travers un pointeur nul y exigerait beaucoup de code en plus, et
la mémoire est déjà ultra-serrée.



Ouais, enfin bon, s'arranger pour que la representation du pointeur nul
soit une trap representation, c'est possible meme sur ces machines.

Et la memoire ultra-serree, c'est sur l'architecture cible. Surtout en C++,
ou ca m'etonnerait que tu aies un compilo natif si la machine est si petite
que ca.

On est vieux tous les deux, on a connu ces vieilles machines. Mais le
temps a passe... sur un truc vaguement contemporain (ce qui est le cas
de MacOS), ce genre de trucs n'est pas tres excusable...
Avatar
pjb
(Marc Espie) writes:

In article ,
James Kanze wrote:
Ça dépend du contexte, je crois. Pour une implémenatation sur
une machine généraliste, genre PC ou station de travail, avec
des MMU et tout, je suis d'accord avec toi. Mais je me suis
servi aussi de C sur des PC 8 bits, avec un maximum de 64 Ko de
mémoire, et pas de protection du tout; détecter un accès à
travers un pointeur nul y exigerait beaucoup de code en plus, et
la mémoire est déjà ultra-serrée.



Ouais, enfin bon, s'arranger pour que la representation du pointeur nul
soit une trap representation, c'est possible meme sur ces machines.

Et la memoire ultra-serree, c'est sur l'architecture cible. Surtout en C++,
ou ca m'etonnerait que tu aies un compilo natif si la machine est si petite
que ca.

On est vieux tous les deux, on a connu ces vieilles machines. Mais le
temps a passe... sur un truc vaguement contemporain (ce qui est le cas
de MacOS), ce genre de trucs n'est pas tres excusable...



Je ne travaille pas beaucoup sur des machines limitées en mémoire (la
plus limitée récement fut un Palm Tungsten C avec 64 MB de RAM...),
mais s'il y a des gens pour écrire des livres sur des design patterns
pour réduire l'utilisation de la mémoire, c'est que ça doit exister,
des "petites" machines, encore maintenant.
http://www.cix.co.uk/~smallmemory/book.html


--
__Pascal Bourguignon__
Avatar
James Kanze
On Aug 25, 12:21 pm, (Marc Espie) wrote:
In article
,
James Kanze wrote:



>Ça dépend du contexte, je crois. Pour une implémenatation sur
>une machine généraliste, genre PC ou station de travail, avec
>des MMU et tout, je suis d'accord avec toi. Mais je me suis
>servi aussi de C sur des PC 8 bits, avec un maximum de 64 Ko
>de mémoire, et pas de protection du tout; détecter un accès à
>travers un pointeur nul y exigerait beaucoup de code en plus,
>et la mémoire est déjà ultra-serrée.



Ouais, enfin bon, s'arranger pour que la representation du
pointeur nul soit une trap representation, c'est possible meme
sur ces machines.



Il n'y avait pas de représentation trap sur un 8086.

Et la memoire ultra-serree, c'est sur l'architecture cible.
Surtout en C++, ou ca m'etonnerait que tu aies un compilo
natif si la machine est si petite que ca.



Le premier compilateur C++ dont je me suis servi, c'était bien
sur un 8086 (sous MS-DOS).

On est vieux tous les deux, on a connu ces vieilles machines.
Mais le temps a passe... sur un truc vaguement contemporain
(ce qui est le cas de MacOS), ce genre de trucs n'est pas tres
excusable...



Tout à fait, au moins pour les machines généralistes. (Pour les
systèmes embarqués, je ne sais pas, mais j'imagine qu'il en
existe même aujourd'hui qui n'ont pas de protection mémoire.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
espie
In article ,
Pascal J. Bourguignon wrote:
Je ne travaille pas beaucoup sur des machines limitées en mémoire (la
plus limitée récement fut un Palm Tungsten C avec 64 MB de RAM...),
mais s'il y a des gens pour écrire des livres sur des design patterns
pour réduire l'utilisation de la mémoire, c'est que ça doit exister,
des "petites" machines, encore maintenant.
http://www.cix.co.uk/~smallmemory/book.html



Ta logique est deficiente. Reduire l'utilisation de la memoire, c'est
utile pour certains types de problemes, meme sur de grosses machines, et donc
ca ne prouve rien quant a l'existence de machines avec peu de memoire...
Ne serait-ce que pour tenir dans le cache, et donc aller plus vite...
mais egalement parce que, si avec 4G tu traites des problemes d'une certaine
taille maximale, eh bien en divisant par deux l'occupation memoire, tu
pourras traiter des problemes plus gros.

Apres, oui, bien sur, il existe des machines avec peu de memoire.
1 2