unions en C, questions sur la norme, alignement - Page 1

supposons le code suivant:

union toto {
uint8_t as8;
uint16_t as16;
uint32_t as32;
}
union toto u;

== &u.as8)est-ce que ((as8*)&u est toujours vrai ou bien est-ce que le uint8 peut se trouver décalé dans les 32bits de l'union?

C'est toujours vrai.

ok merci

Oui sur les unions, normalement tous les element sont aligné du meme coté (donc sur le début de la zone)

Sinon l'interet de l'union serait largement moindre

Pourquoi il serait moindre ?

[edit] : Euh j'ai compris tout seul.

Parce qu'avec une union par exemple on peut faire

union toto {
  struct {
    int type;
  } any;
  struct chaine {
    int type;
    char *content;
  } chaine;
  struct flottant {
    int type;
    float valeur;
  } flottant;
};

et transformer &toto.any en &toto.chaine par simple cast vers (struct chaine *)

Par contre, c'est vrai qu'avec tous les autres types de données la norme ne garantit rien quant à ce qui se passe (si on stocke une valeur dans u.as16, on n'a absolument pas le droit de lire dans u.as8, ou même de caster &u.as16 en (uint8_t *) pour y lire), donc a priori ça n'est pas extraordinairement intéressant... Disons que syntaxiquement ça peut alléger un peu les choses (si on a p = (void *)&toto, alors (uint8_t *)p est équivalent à &toto.as8), que ça a toujours correspondu à la réalité avec les compilateurs "traditionnels", et que la norme a pour vocation de représenter au mieux l'ensemble des compilateurs traditionnels sans couper les cheveux en quatre si ça n'est pas nécessaire : du coup comme ça simplifie l'intuition qu'on a des union de pouvoir supposer ça et que ça ne nuit pas a priori aux performances, c'est ce qui a été décidé

Pollux> ...et avoir la certitude que le champ type reste valide.
(je me doute que c'est ce que tu voulais montrer, mais ça va toujours mieux en le disant )

ça me sert car j'utilise les unions pour alléger la syntaxe mais je n'alloue que la taille vraiment prise par les données (c'est une erreur sémantique certes mais ça fonctionne)
de même, je stocke des tableaux en allouant leur vraie taille mais je ne fais figurer dans les unions que leur premier élémént et j'y accède par (&union.tableau.premierelement)[N]

de même, je stocke des tableaux en allouant leur vraie taille mais je ne fais figurer dans les unions que leur premier élémént et j'y accède par

Alors je ne vais pas m'avancer sur la norme, j'ai pas été regarder. Mais il me semble que c'est tout ce qu'il y a de plus standard ça non comme façon de faire ?
GCC a même une extension permettant de créer un tableau de 0 éléments, à cet usage (ne peut être utilisé qu'en fin de structure).

Pas tout à fait :
- déjà il faut déclarer une structure contenant un tableau, et pas un élément isolé (donc ce serait union.tableau.tableau_incomplet[N] au lieu de (&union.tableau.premierelement)[N])
- ensuite ce n'est pas parce que tu peux effectivement déclarer un tableau de 42 éléments et le caster en ta structure contenant un tableau incomplet, que tu peux ensuite caster cette structure vers l'union... Tu peux transformer une union en tableau incomplet, mais pas un tableau incomplet en union

arf, effectivement j'ai mal lu. J'ai sauté une étape dans la déclaration, ce qui donne une réponse à l'ouest.
En fait j'ai complètement oublié l'étape union dans l'affaire.

je me suis arrangé pour que toutes les structures de l'union aient la même taille exprès

Ca tu peux pas le savoir
A moins d'avoir exactement les mêmes types exactement dans le même ordre.

j'utilise les types de stdint.h comme ça je suis sûr de la taille

s'il ne sont pas dans le même ordre, tu as le risque d'avoir une quantité de padding différente pour chaque structure.

ceux que j'utilise via des casts pour mes structures sont dans le même ordre et au début, le reste varie parfois mais reste à taille fixe

enfin je ne m'exprime pas très bien peut être mais j'ai bien fait gaffe à ce qu'il n'y ait pas d'ambiguïté possible, norme à la main