[C++ 64 bits] cast pointeur <-> int

Résolu/Fermé
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 - 13 févr. 2008 à 09:58
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 - 15 févr. 2008 à 08:32
Bonjour,
J'ai un code qui en gros fait ça :
Element T;
int f=&T;
Element *pT=(Element*) f;

ce code ne pose pas de problème en 32 bits, car le int a la même taille que le pointeur (Element*) En revanche, en 64 bits, le pointeur est codé sur plus de bits que le int.
Le compilateur me revoie un "warning" comme quoi je cast un élement trop petit.
Je voulais savoir si ce warning est vraiment important et si oui, à quelles types d'erreurs ou de problème cela expose.
A voir également:

5 réponses

Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 125
13 févr. 2008 à 19:52
Bonjour,

A vrai dire je n'ai jamais essayé donc c'est à prendre avec des pincettes.

Pour faire simple, ton programme tronque les 32 premiers bits.

Si on prend par exemple le cas de Windows, cela coupe la page mémoire et peut-être un morceau de la ligne à lire. L'application tentera alors de lire une autre ligne d'une autre page, celle correspondant à l'adresse commençant par 32 zéros. Si tu as de la chance ton adresse commençait déjà par 32 zéros. (très improbable de vouloir accéder à la première page...) Dans le cas d'une application utilisateur, Windows te verra car il a protégé ses affaires et fermera ton programme.

C'est là le scénario le plus probable bienque je n'ai jamais essayé. Il se peut aussi que d'autre système autorise à lire ou modifier ce qu'il y a à cette adresse.

M.
0
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 125
13 févr. 2008 à 20:00
Whoops...

La solution, déclarer avec un typedef un type de la bonne taille selon que l'on est en 32 ou 64 bits.

Sous Windows ce type existe, voir ULONG_PTR et PULONG_PTR par exemple.

M.
0
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 1 298
14 févr. 2008 à 14:20
Ok, merci.
C'est aussi ce que je pensais. J'ai remplacé partout ou le compilateur me mettait un warning les int par le type POINTEUR défini comme un typedef de long int.
Le souci, c'est que c'est un code d'environ 1000 fichiers et que j'aurai toujours un doute sur le fait d'avoir bien tout modifier.
Pour l'instant le programme se déroule comme il faut, il faut croire que toute mes adresses commencent par de zéros...
J'ai peur d'avoir des erreurs étranges dans l'avenir et d'oublier d'où elles peuvent venir.
0
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 125
14 févr. 2008 à 19:31
Méfiance méfiance, d'après la MSDN (LA référence du programmeur Windows) le long est codé sur 32 bits même sur OS 64 bits de la marque (exemple ici)

Il se peut très bien que cela soit différent suivant l'OS ou le compilateur utilisé.
(Quel bonheur hein ?)

Par chez moi, nous allons définir tous nos type primitifs à grands coups de typedef afin d'être toujours sûr de ce que l'on manipule.

M.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 1 298
15 févr. 2008 à 08:32
En fait, je compile sous 64 bits uniquement sous Linux. Mais merci de l'information, car dans les années à venir, nous serons surement amener à compiler sous 64 avec Windows. D'un autre coté, la MSDN parle essentiellement du compilo MS, nous utilisons gcc.
Mais de toute façon, c'est facile à tester avec sizeof, et comme tu le dit, le typedef permet de modifier l'ensemble du code en quelques touches de clavier.
Comme quoi il vaut mieux toujours éviter ce qui n'est pas standard, car un jour ou l'autre on se trouve emmerder.
0