Path: ...!news.mixmin.net!aioe.org!Faqf6A55NG1s8DSVkh3L9A.user.46.165.242.75.POSTED!not-for-mail From: Alain Ketterlin Newsgroups: fr.comp.lang.python Subject: Re: =?utf-8?Q?probl=C3=A8me?= avec struct.calcsize qui retourne la =?utf-8?Q?m=C3=AAme?= valeur alors qu'un entier non =?utf-8?Q?sign=C3=A9?= a =?utf-8?B?w6l0w6kgYWpvdXTDqQ==?= au formatage Date: Fri, 04 Feb 2022 22:55:18 +0100 Organization: =?utf-8?Q?Universit=C3=A9?= de Strasbourg Message-ID: <87tudenvp5.fsf@universite-de-strasbourg.fr.invalid> References: <87zgn65whh.fsf@izac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: gioia.aioe.org; logging-data="46773"; posting-host="Faqf6A55NG1s8DSVkh3L9A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cancel-Lock: sha1:l3V0M/ptLq1Hy21Sculs7QxyZYM= X-Notice: Filtered by postfilter v. 0.9.2 Bytes: 3731 Lines: 64 Benoit Izac writes: > Le 04/02/2022 =C3=A0 16:29, "pata...@gmail.com" a = =C3=A9crit > dans le message > =C2=A0: >> python -c 'import struct; print(struct.calcsize("4sIQ5I2Q"), >> 4+4+8+(5*4)+(2*8))' >> 56 52 >> une explication ? > J'imagine que =C3=A7a vient de l=C3=A0=C2=A0: > , notamment > . C'est =C3=A7a : l'alignement des deux derniers Q est 8 octets, mais la taile de ce qui pr=C3=A9c=C3=A8de est congru =C3=A0 4 modulo 8. En clair pour la = structure enti=C3=A8re ([x,y[ est l'intervalle x inclus y exclu), on commence en position 0 : 00: 4s (4*1 octet, alignement 1 =3D ok) -> [0:4[ 04: I (1*4 octets, alignement 4 =3D ok) -> [4:8[ 08: Q (1*8 octets, alignement 8 =3D ok) -> [8:16[ 16: 5I (5*4 octets, alignement 4 =3D ok) -> [16:36[ 36: 2Q (2*8 octets, alignement 8 =3D probl=C3=A8me, 36 est pas multiple de = 8) =3D> padding de 4 octets pour aligner -> [36:40[ =3D> puis 2Q -> [40:56[ La contrainte d'alignement d=C3=A9pend de l'architecture (et de choix du compilateur). Un Q (unsigned long long en C) doit en g=C3=A9n=C3=A9ral =C3= =AAte align=C3=A9 sur 8 octets (c'est le cas ici). Donc oui, il y a 4 octets dans la structure qui ne servent =C3=A0 rien (entre 36 et 40 si je me suis pas gour= =C3=A9 dans les calculs). C'est d'ailleurs pour cela qu'on ne peut pas tester l'=C3=A9galit=C3=A9 de structures octet par octet en C (le padding peut con= tenir n'importe quoi). Pour la m=C3=AAme raison, tu trouveras (s=C3=BBrement) que "sQ" a une taill= e de 16, de m=C3=AAme que "IQ", de m=C3=AAme que "QI" Dans ce dernier exemple, le padding est =C3=A0 la fin, mais il doit =C3=AAtre l=C3=A0 pour le cas o=C3= =B9 tu veux faire un tableau de telles structures (le deuxi=C3=A8me =C3=A9l=C3=A9ment du tabl= eau doit =C3=AAtre align=C3=A9 sur un multiple de 8). Certaines architectures acceptent des donn=C3=A9es non align=C3=A9es, par e= xemple des "long long" de 8 octets align=C3=A9s sur 4 octets, mais en g=C3=A9n=C3= =A9ral il faut le demander explicitement, par exemple avec l'attribut "packed" en C avec gcc et d'autres. C'est non portable. Et m=C3=AAme si l'architecture = le supporte, cela peut =C3=AAtre plus lent, parce qu'une donn=C3=A9e peut se t= rouver =C3=A0 cheval sur deux lignes de cache. -- Alain.