Accès à un membre du syndicat inactif et comportement indéfini?

J'avais l'impression que l'accès à un union membre autre que le dernier ensemble est UB, mais je n'arrive pas à trouver une référence solide (autre que des réponses affirmant que c'est UB mais sans aucun support de la norme).

Alors, est-ce un comportement non défini?

La confusion est que C autorise explicitement le poinçonnage de type via une union, alors que C ++ (c ++ 11) n'a pas une telle autorisation.

c11

6.5.2.3 Structure et membres du syndicat

95) Si le membre utilisé pour lire le contenu d'un objet union n'est pas le même que le dernier membre utilisé pour stocker une valeur dans l'objet, la partie appropriée de la représentation d'objet de la valeur est réinterprétée comme une représentation d'objet dans le nouveau tapez comme décrit dans 6.2.6 (un processus parfois appelé «poinçonnage de type»). Cela pourrait être une représentation piège.

La situation avec C ++:

c ++ 11

9.5 Unions [class.union]

Dans une union, au plus l'un des membres de données non statiques peut être actif à tout moment, c'est-à-dire que la valeur d'au plus l'un des membres de données non statiques peut être stockée dans une union à tout moment.

C ++ a plus tard un langage permettant l'utilisation d'unions contenant des structs avec des séquences initiales communes; cela ne permet cependant pas le poinçonnage de type.

Pour déterminer si la punition de type d'union est autorisé en C ++, nous devons chercher plus loin. Rappeler quec99 est une référence normative pour C ++ 11 (et C99 a un langage similaire à C11 permettant l'union de type-punning):

3.9 Types [basic.types]

4 - La représentation objet d'un objet de type T est la suite de N objets char non signés repris par l'objet de type T, où N est égal à sizeof (T). La représentation de valeur d'un objet est l'ensemble de bits qui contiennent la valeur de type T.Pour les types trivialement copiables, la représentation de valeur est un ensemble de bits dans la représentation d'objet qui détermine une valeur, qui est un élément discret d'une implémentation. ensemble de valeurs défini. ⁴²
42) L'intention est que le modèle de mémoire de C ++ soit compatible avec celui du langage de programmation ISO / CEI 9899 C.

Cela devient particulièrement intéressant quand on lit

3.8 Durée de vie de l'objet [basic.life]

La durée de vie d'un objet de type T commence lorsque: - le stockage avec l'alignement et la taille appropriés pour le type T est obtenu, et - si l'objet a une initialisation non triviale, son initialisation est terminée.

Ainsi, pour un type primitif (qui a ipso facto une initialisation triviale) contenu dans une union, la durée de vie de l'objet englobe au moins la durée de vie de l'union elle-même. Cela nous permet d'invoquer

3.9.2 Types composés [basic.compound]

Si un objet de type T se trouve à une adresse A, on dit qu'un pointeur de type cv T * dont la valeur est l'adresse A pointe vers cet objet, quelle que soit la manière dont la valeur a été obtenue.

En supposant que l'opération qui nous intéresse est le poinçonnage de type, c'est-à-dire qu'elle prend la valeur d'un membre syndical non actif, et que, conformément à ce qui précède, nous avons une référence valide à l'objet auquel ce membre fait référence, cette opération est lvalue-to -rvaleur conversion:

4.1 Conversion Lvalue-to-rvalue [conv.lval]

Une glvalue d'un type non-function, non-array Tpeut être convertie en prvalue. Si Test un type incomplet, un programme qui nécessite cette conversion est mal formé. Si l'objet auquel se réfère la valeur de glissement n'est pas un objet de type Tet n'est pas un objet d'un type dérivé de T, ou si l'objet n'est pas initialisé, un programme qui nécessite cette conversion a un comportement non défini.

La question est alors de savoir si un objet qui est un membre syndical non actif est initialisé par stockage sur le membre syndical actif. Pour autant que je sache, ce n'est pas le cas et donc si:

• une union est copiée dans le charstockage de la baie et inversement (3.9: 2), ou
• une union est copiée par octet dans une autre union du même type (3.9: 3), ou
• une union est accessible au-delà des frontières linguistiques par un élément de programme conforme à ISO / CEI 9899 (pour autant que cela soit défini) (3.9: 4 note 42), alors

l'accès à une union par un membre non actif est défini et est défini pour suivre la représentation de l'objet et de la valeur, l'accès sans l'une des interpositions ci-dessus est un comportement indéfini. Cela a des implications pour les optimisations autorisées à être effectuées sur un tel programme, car l'implémentation peut bien sûr supposer qu'un comportement indéfini ne se produit pas.

Autrement dit, bien que nous puissions légitimement former une lvalue à un membre syndical non actif (c'est pourquoi l'attribution à un membre non actif sans construction est acceptable), elle est considérée comme non initialisée.

La norme C ++ 11 le dit de cette façon

9.5 Syndicats

Dans une union, au plus l'un des membres de données non statiques peut être actif à tout moment, c'est-à-dire que la valeur d'au plus l'un des membres de données non statiques peut être stockée dans une union à tout moment.

Si une seule valeur est stockée, comment pouvez-vous en lire une autre? Ce n'est tout simplement pas là.

La documentation gcc le répertorie sous Comportement défini par l'implémentation

• L'accès à un membre d'un objet union s'effectue à l'aide d'un membre d'un type différent (C90 6.3.2.3).

Les octets pertinents de la représentation de l'objet sont traités comme un objet du type utilisé pour l'accès. Voir Punition de type. Cela peut être une représentation piège.

indiquant que cela n'est pas exigé par la norme C.

2016-01-05: Grâce aux commentaires, j'ai été lié au rapport de défaut C99 n ° 283 qui ajoute un texte similaire en tant que note de bas de page au document standard C:

78a) Si le membre utilisé pour accéder au contenu d'un objet union n'est pas le même que le dernier membre utilisé pour stocker une valeur dans l'objet, la partie appropriée de la représentation d'objet de la valeur est réinterprétée comme une représentation d'objet dans le nouveau tapez comme décrit en 6.2.6 (un processus parfois appelé "poinçonnage de type"). Cela pourrait être une représentation piège.

Je ne sais pas si cela clarifie beaucoup, étant donné qu'une note de bas de page n'est pas normative pour la norme.

Je pense que le plus proche de la norme vient de dire que son comportement indéfini est celui où il définit le comportement d'une union contenant une séquence initiale commune (C99, §6.5.2.3 / 5):

Une garantie particulière est faite afin de simplifier l'utilisation des unions: si une union contient plusieurs structures qui partagent une séquence initiale commune (voir ci-dessous), et si l'objet union contient actuellement l'une de ces structures, il est permis d'inspecter le commun partie initiale de l'un d'entre eux partout où une déclaration du type complet de l'union est visible. Deux structures partagent une séquence initiale commune si les membres correspondants ont des types compatibles (et, pour les champs de bits, les mêmes largeurs) pour une séquence d'un ou plusieurs membres initiaux.

C ++ 11 donne des exigences / autorisations similaires au §9.2 / 19:

Si une union de mise en page standard contient deux ou plusieurs structures de mise en page standard qui partagent une séquence initiale commune, et si l'objet union de mise en page standard contient actuellement l'une de ces structures de mise en page standard, il est permis d'inspecter la partie initiale commune de tout d'eux. Deux structures de mise en page standard partagent une séquence initiale commune si les membres correspondants ont des types compatibles avec la mise en page et qu'aucun membre n'est un champ de bits ou les deux sont des champs de bits de la même largeur pour une séquence d'un ou plusieurs membres initiaux.

Bien que ni l'un ni l'autre ne le déclare directement, ces deux éléments impliquent fortement que "inspecter" (lire) un membre n'est "autorisé" que si 1) il fait (partie de) le membre le plus récemment écrit, ou 2) fait partie d'une initiale commune séquence.

Ce n'est pas une déclaration directe que faire autrement est un comportement indéfini, mais c'est le plus proche dont je suis conscient.

Quelque chose qui n'est pas encore mentionné par les réponses disponibles est la note de bas de page 37 au paragraphe 21 de la section 6.2.5:

Notez que le type d'agrégat n'inclut pas le type d'union car un objet de type union ne peut contenir qu'un seul membre à la fois.

Cette exigence semble clairement impliquer que vous ne devez pas écrire dans un membre et lire dans un autre. Dans ce cas, il peut s'agir d'un comportement indéfini par manque de spécification.

J'explique bien cela avec un exemple.
supposons que nous ayons l'union suivante:

union A{
   int x;
   short y[2];
};

Je suppose bien que cela sizeof(int)donne 4, et cela sizeof(short)donne 2.
quand vous écrivezunion A a = {10} bien, créez une nouvelle var de type A en lui mettant la valeur 10.

votre mémoire devrait ressembler à ça: (rappelez-vous que tous les membres du syndicat ont le même emplacement)

       | x |
       | y [0] | y [1] |
       -----------------------------------------
   a-> | 0000 0000 | 0000 0000 | 0000 0000 | 0000 1010 |
       -----------------------------------------

comme vous pouvez le voir, la valeur de ax est 10, la valeur de ay 1 est 10 et la valeur de ay [0] est 0.

maintenant, que se passe-t-il si je fais ça?

a.y[0] = 37;

notre mémoire ressemblera à ceci:

       | x |
       | y [0] | y [1] |
       -----------------------------------------
   a-> | 0000 0000 | 0010 0101 | 0000 0000 | 0000 1010 |
       -----------------------------------------

cela transformera la valeur de ax à 2424842 (en décimal).

maintenant, si votre union a un flottant, ou double, votre carte mémoire sera bien plus en désordre, à cause de la façon dont vous stockez les nombres exacts. plus d'informations que vous pourriez obtenir ici .