🚀 go-pugleaf

Le 19-10-2005, Antoine Leca <root@localhost.invalid> a �crit�:
> 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...)

  Bon, que cela ne t'apparaisse pas limpide � toi non plus
rend ma propre interrogation moins honteuse.

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

  OK

>> 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...

  En effet.

> �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�...

  OK.

> 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.

   "inspect" vs "access" Faut faire attention � chaque mot en effet.

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

  Pourtant, �a me semble moins dur que le reste.

>> 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).

  C'est � dire qu'on a pas (void*)&f == (void*)&f.j == (void*) &f.k ?

Marc Boyer
-- 
� v�lo, prendre une rue � contre-sens est moins dangeureux
que prendre un boulevard dans le sens l�gal. � qui la faute ?