🚀 go-pugleaf

Marc Boyer wrote:

Ce genre de question sont trait�es (par forc�ment de mani�re limpides ;-))
dans les paragraphes 6.2 et 6.3. Bonne lecture (non, je ne fournis pas
l'aspirine...)

En g�neral, plut�t que int, il vaut mieux r�fl�chir avec des types tordus,
genre long double 80 bits sur Intel...


> A) Struct qui commencent pareil
>   Soient
> typedef struct { int i; } Si;
> typedef struct { int i; char c;} Sic;
>    Sic sic;
>    Si* psi= (Si*) &sic;
>    psi->i= 1;   // Est-ce l�gal ? Si oui, un ref ?

D'une part,

   6.2.5  Types

   [#26]  All pointers to
   structure types  shall  have  the  same  representation  and
   alignment requirements as each other.  All pointers to union
   types shall  have  the  same  representation  and  alignment
   requirements  as  each  other.  Pointers to other types need
   not have the same representation or alignment  requirements.

me para�t interdire une impl�mentation o� les propri�t�s de Si* et Sic*
(genre des types diff�rents de segmentation, _huge* contre _far* ou ce genre
d'horreur) les rendraient incommensurable, donc je pense que le transtypage
de la ligne sup�rieure est l�gal (pas faire boum).

� partir de l�, l'affectation en elle-m�me ne me para�t pas poser de
probl�me... tant que l'on en reste l� !

Par contre, je me pose des questions sur la suite, par exemple sur une
possible subs�quente utilisation de sic.c qui aurait �t� pr�alablement
initialis�...
Par exemple, imaginons une architecture o� l'acc�s � un Si ou � un Sic a le
m�me co�t pour le processeur [non, je ne fournis pas l'aspirine]. Un
compilateur normal va donc allouer la m�me taille aux deux structures (avec
plus de remplissage au bout de Si). L'affectation via psi->i n'a pas de
raison de s'int�resser particuli�rement � cet espace de remplissage, et
comme sur mon hypoth�tique machine c'est moins cher de ranger le tout en
bloc, l'affectation va potentiellement �craser le membre c...


�videmment, dans ton cas particulier avec un membre de type int, j'ai
beaucoup de mal � imaginer une telle machine ;-). Mais remplace int par long
double et alors l�...


L'utilisation d'une union englobante pour faire valoir la r�gle de 6.5.2.3p5
comme l'explique tr�s bien Jean-Marc par ailleurs, ne vaut que pour les
examens ("permitted to inspect the common initial part"), donc pour moi ne
s'applique pas ici.


La question � laquelle je ne r�pond pas (sciemment), c'est la valeur de
sic.i apr�s l'affectation via psi->i :-)


> B) Union avec les m�me champs
>   union { char j,k; } f;
>    f.j= 'a';
>    assert( f.j == f.k); // Est-ce l�gal ? Si oui, ref ?

   6.2.6  Representations of types
   6.2.6.1  General

   [#7] When a value is stored in a  member  of  an  object  of
   union  type,  the bytes of the object representation that do
   not correspond to that member but  do  correspond  to  other
   members  take unspecified values, but the value of the union
   object shall not thereby become a trap representation.

Donc cela parait l�gal (pas possible de faire sauter la baraque), mais par
contre ton programme n'est pas strictement conforme (on peut imaginer des
impl�mentations qui surveillent l'assignations aux membres des unions, donc
vont r�pondre non � l'assertion et faire varier le comportement du
programme).


Antoine