Disons en fait, hrum, c'est assez compliqué. Evidement que les pointeurs 32 bits ne seront pas utilisés dans l'architecture 64 bits, c'est dans le but d'avoir un système suffisement homogène pour faire transiter les informations. Les pointeurs propres ne peuvent bien sûr qu'êtres utilisés localement. C'est surtout que dans l'optique d'un système client/serveur, imagine qu'un client 64 bits converse avec un serveur 32 bits et lui confie une structure avec un pointeur. Le serveur n'a pas accès à cette portion de la mémoire locale au client, par contre il existe un moyen de lui demander cette portion de mémoire par message-passing. Pour cela il lui faut être en mesure d'envoyer une requête avec le bon pointeur, en 64 bits. Je sais, c'est pô clair...

Pour faire simple, je suis en train d'écrire un linked-in driver en Erlang (d'où message-passing) sur mon Atom 330 (64 bits) et ma Via C7 (32 bits). Pour aller le plus vite possible dans les échanges SANS faire transiter des portions de mémoire j'utilise des structures avec pointeurs. C'est seulement QUAND le serveur à besoin de certaines données qu'il renvoie le handle correspondant (en fait le pointeur) sous forme de requête. A ce moment un échange de données brutes prend place.

C'est pourquoi j'ai IMPERATIVEMENT besoin que la struct source corresponde bit-à-bit à celle de destination, d'où essayer de simuler le packing d'une plateforme 64 bits sur une plateforme 32 bits. Ou alors il reste la solution de 'packer' la structure avec #pragma pack(1) avant de la faire transiter, évitant les octets de padding, mais ça rend la structure inutilisable d'un point de vu run-time (désalignement des données, alignment fault).

Kochise