Je fais habituellement mumuse (avec python, entre autres) sur deux
debian (les mêmes installées) : une en 32 bits et une en 64 bits.
Or le type long sur l'arch 32 bits a une taille de 4 octets,
et sur l'arch 64 bits, il a une taille de 8 octets.
Ça me pose donc un problème (et pas que de conscience).
Une explication ?
Deplus, si sur l'arch 64 bits, le long fait 8 octets,
struct.calcsize('<l') (little-endian) et struct.calcsize('>l')
(big-endian) me renvoient tous les deux... 4.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Pitrou
On Fri, 16 Jan 2009 17:15:34 +0100, fred wrote:
Deplus, si sur l'arch 64 bits, le long fait 8 octets, struct.calcsize('<l') (little-endian) et struct.calcsize('>l') (big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html, voir en particulier la table présentant "byte order" et "size and alignment" en fonction du code utilisé. En résumé, le long fera effectivement 8 octets si tu demandes la taille "native", mais 4 octets si tu demandes la taille standard.
C'est un peu étrange mais quand on y réfléchit ça fait sens : soit on veut un format correspondant exactement aux caractéristiques de la machine hôte et, en ne spécifiant pas de modificateur ('<', '>', etc.) on obtient la taille native en plus de l'ordre natif. Soit on veut être interopérable en forçant l'ordre et la taille est donc standardisée au lieu de varier de machine à machine.
Je cite la doc texto : « Native size and alignment are determined using the C compiler’s sizeof expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required for any type (so you have to use pad bytes); short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and double are 32-bit and 64-bit IEEE floating point numbers, respectively. _Bool is 1 byte. »
On Fri, 16 Jan 2009 17:15:34 +0100, fred wrote:
Deplus, si sur l'arch 64 bits, le long fait 8 octets,
struct.calcsize('<l') (little-endian) et struct.calcsize('>l')
(big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html,
voir en particulier la table présentant "byte order" et "size and
alignment" en fonction du code utilisé. En résumé, le long fera
effectivement 8 octets si tu demandes la taille "native", mais 4 octets
si tu demandes la taille standard.
C'est un peu étrange mais quand on y réfléchit ça fait sens : soit on
veut un format correspondant exactement aux caractéristiques de la
machine hôte et, en ne spécifiant pas de modificateur ('<', '>', etc.) on
obtient la taille native en plus de l'ordre natif. Soit on veut être
interopérable en forçant l'ordre et la taille est donc standardisée au
lieu de varier de machine à machine.
Je cite la doc texto : « Native size and alignment are determined using
the C compiler’s sizeof expression. This is always combined with native
byte order.
Standard size and alignment are as follows: no alignment is required for
any type (so you have to use pad bytes); short is 2 bytes; int and long
are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and double
are 32-bit and 64-bit IEEE floating point numbers, respectively. _Bool is
1 byte. »
Deplus, si sur l'arch 64 bits, le long fait 8 octets, struct.calcsize('<l') (little-endian) et struct.calcsize('>l') (big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html, voir en particulier la table présentant "byte order" et "size and alignment" en fonction du code utilisé. En résumé, le long fera effectivement 8 octets si tu demandes la taille "native", mais 4 octets si tu demandes la taille standard.
C'est un peu étrange mais quand on y réfléchit ça fait sens : soit on veut un format correspondant exactement aux caractéristiques de la machine hôte et, en ne spécifiant pas de modificateur ('<', '>', etc.) on obtient la taille native en plus de l'ordre natif. Soit on veut être interopérable en forçant l'ordre et la taille est donc standardisée au lieu de varier de machine à machine.
Je cite la doc texto : « Native size and alignment are determined using the C compiler’s sizeof expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required for any type (so you have to use pad bytes); short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and double are 32-bit and 64-bit IEEE floating point numbers, respectively. _Bool is 1 byte. »
fred
Antoine Pitrou a écrit :
On Fri, 16 Jan 2009 17:15:34 +0100, fred wrote:
Deplus, si sur l'arch 64 bits, le long fait 8 octets, struct.calcsize('<l') (little-endian) et struct.calcsize('>l') (big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html, voir en particulier la table présentant "byte order" et "size and alignment" en fonction du code utilisé. En résumé, le long fera effectivement 8 octets si tu demandes la taille "native", mais 4 octets si tu demandes la taille standard.
[snip]
Ok merci pour le lien.
Le problème est que j'ai récupéré un code ici :
http://segymat.sourceforge.net/segypy
qui fonctionne très sur une arch 32 bits et qui ne fonctionne pas sur une arch 64 bits.
Erreur de la part du développeur ?
-- Fred
Antoine Pitrou <pitrou@f.r.e.e.fr> a écrit :
On Fri, 16 Jan 2009 17:15:34 +0100, fred wrote:
Deplus, si sur l'arch 64 bits, le long fait 8 octets,
struct.calcsize('<l') (little-endian) et struct.calcsize('>l')
(big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html,
voir en particulier la table présentant "byte order" et "size and
alignment" en fonction du code utilisé. En résumé, le long fera
effectivement 8 octets si tu demandes la taille "native", mais 4 octets
si tu demandes la taille standard.
[snip]
Ok merci pour le lien.
Le problème est que j'ai récupéré un code ici :
http://segymat.sourceforge.net/segypy
qui fonctionne très sur une arch 32 bits et qui ne fonctionne pas sur
une arch 64 bits.
Deplus, si sur l'arch 64 bits, le long fait 8 octets, struct.calcsize('<l') (little-endian) et struct.calcsize('>l') (big-endian) me renvoient tous les deux... 4.
C'est expliqué dans la doc à http://docs.python.org/library/struct.html, voir en particulier la table présentant "byte order" et "size and alignment" en fonction du code utilisé. En résumé, le long fera effectivement 8 octets si tu demandes la taille "native", mais 4 octets si tu demandes la taille standard.
[snip]
Ok merci pour le lien.
Le problème est que j'ai récupéré un code ici :
http://segymat.sourceforge.net/segypy
qui fonctionne très sur une arch 32 bits et qui ne fonctionne pas sur une arch 64 bits.
