¿Acceso a un miembro sindical inactivo y comportamiento indefinido?

Tenía la impresión de que acceder a un unionmiembro que no sea el último conjunto es UB, pero parece que no puedo encontrar una referencia sólida (aparte de las respuestas que afirman que es UB pero sin ningún apoyo del estándar).

Entonces, ¿es un comportamiento indefinido?

La confusión es que C permite explícitamente la escritura de tipos mediante una unión, mientras que C ++ (c ++ 11) no tiene dicho permiso.

c11

6.5.2.3 Estructura y miembros del sindicato

95) Si el miembro utilizado para leer el contenido de un objeto de unión no es el mismo que el miembro utilizado por última vez para almacenar un valor en el objeto, la parte apropiada de la representación del objeto del valor se reinterpreta como una representación de objeto en el nuevo escriba como se describe en 6.2.6 (un proceso a veces llamado "punzonado de tipo"). Esto podría ser una representación trampa.

La situación con C ++:

c ++ 11

9.5 Uniones [class.union]

En una unión, como máximo uno de los miembros de datos no estáticos puede estar activo en cualquier momento, es decir, el valor de como máximo uno de los miembros de datos no estáticos puede almacenarse en una unión en cualquier momento.

C ++ más tarde tiene lenguaje que permite el uso de uniones que contienen structs con secuencias iniciales comunes; Sin embargo, esto no permite la escritura de tipos.

Para determinar si la unión de tipos está permitida en C ++, tenemos que buscar más. Recordar quec99 es una referencia normativa para C ++ 11 (y C99 tiene un lenguaje similar al C11 que permite la unión de tipos):

3.9 Tipos [tipos.básicos]

4 - La representación de objeto de un objeto de tipo T es la secuencia de N objetos de caracteres sin signo tomados por el objeto de tipo T, donde N es igual a sizeof (T). La representación del valor de un objeto es el conjunto de bits que contienen el valor del tipo T. Para los tipos que se pueden copiar trivialmente, la representación del valor es un conjunto de bits en la representación del objeto que determina un valor, que es un elemento discreto de una implementación. conjunto de valores definido. ⁴²
42) La intención es que el modelo de memoria de C ++ sea compatible con el del lenguaje de programación ISO / IEC 9899 C.

Se pone particularmente interesante cuando leemos

3.8 Vida útil del objeto [basic.life]

La vida útil de un objeto de tipo T comienza cuando: - se obtiene el almacenamiento con la alineación y el tamaño adecuados para el tipo T, y - si el objeto tiene una inicialización no trivial, su inicialización está completa.

Entonces, para un tipo primitivo (que ipso facto tiene una inicialización trivial) contenido en una unión, la vida útil del objeto abarca al menos la vida útil de la unión misma. Esto nos permite invocar

3.9.2 Tipos de compuestos [basic.compound]

Si un objeto de tipo T se encuentra en una dirección A, se dice que un puntero de tipo cv T * cuyo valor es la dirección A apunta a ese objeto, independientemente de cómo se obtuvo el valor.

Suponiendo que la operación en la que estamos interesados ​​es la escritura de tipos, es decir, tomar el valor de un miembro de la unión no activo, y dado lo anterior que tenemos una referencia válida al objeto al que hace referencia ese miembro, esa operación es lvalue-to -conversión de valor:

4.1 Conversión Lvalue-to-rvalue [conv.lval]

Un valor de gl de un tipo sin función, sin matriz Tse puede convertir en un valor pr. Si Tes un tipo incompleto, un programa que necesita esta conversión está mal formado. Si el objeto al que se refiere el valor gl no es un objeto de tipo Ty no es un objeto de un tipo derivado de T, o si el objeto no está inicializado, un programa que necesita esta conversión tiene un comportamiento indefinido.

La pregunta entonces es si un objeto que es un miembro de la unión no activo se inicializa por almacenamiento en el miembro de la unión activa. Por lo que puedo decir, este no es el caso y, aunque si:

• una unión se copia en el charalmacenamiento de matriz y viceversa (3.9: 2), o
• una unión se copia por byte en otra unión del mismo tipo (3.9: 3), o
• Se accede a una unión a través de los límites del idioma mediante un elemento del programa conforme a ISO / IEC 9899 (hasta donde se define) (3.9: 4 nota 42), luego

el acceso a una unión por un miembro no activo se define y se define para seguir la representación del objeto y valor, el acceso sin una de las interposiciones anteriores es un comportamiento indefinido. Esto tiene implicaciones para las optimizaciones permitidas en dicho programa, ya que la implementación puede, por supuesto, asumir que no ocurre un comportamiento indefinido.

Es decir, aunque podemos formar legítimamente un valor l para un miembro sindical no activo (razón por la cual está bien asignar a un miembro no activo sin construcción) se considera no inicializado.

El estándar C ++ 11 lo dice de esta manera

9.5 Uniones

En una unión, como máximo uno de los miembros de datos no estáticos puede estar activo en cualquier momento, es decir, el valor de como máximo uno de los miembros de datos no estáticos puede almacenarse en una unión en cualquier momento.

Si solo se almacena un valor, ¿cómo puede leer otro? Simplemente no está ahí.

La documentación de gcc enumera esto en Comportamiento definido de implementación

• Se accede a un miembro de un objeto de unión utilizando un miembro de un tipo diferente (C90 6.3.2.3).

Los bytes relevantes de la representación del objeto se tratan como un objeto del tipo utilizado para el acceso. Ver Type-punning. Esto puede ser una representación trampa.

indicando que esto no es requerido por el estándar C.

2016-01-05: A través de los comentarios, me vinculé al Informe de defectos C99 # 283 que agrega un texto similar como una nota al pie del documento estándar C:

78a) Si el miembro utilizado para acceder al contenido de un objeto de unión no es el mismo que el miembro utilizado por última vez para almacenar un valor en el objeto, la parte apropiada de la representación del objeto del valor se reinterpreta como una representación de objeto en el nuevo escriba como se describe en 6.2.6 (un proceso a veces llamado "punzonamiento de tipo"). Esto podría ser una representación trampa.

Sin embargo, no estoy seguro si aclara mucho, considerando que una nota al pie no es normativa para el estándar.

Creo que lo más cercano al estándar es decir que su comportamiento indefinido es donde define el comportamiento para una unión que contiene una secuencia inicial común (C99, §6.5.2.3 / 5):

Se hace una garantía especial para simplificar el uso de las uniones: si una unión contiene varias estructuras que comparten una secuencia inicial común (ver más abajo), y si el objeto de unión actualmente contiene una de estas estructuras, se permite inspeccionar las comunes. parte inicial de cualquiera de ellos en cualquier lugar que sea visible una declaración del tipo completo de la unión. Dos estructuras comparten una secuencia inicial común si los miembros correspondientes tienen tipos compatibles (y, para campos de bits, los mismos anchos) para una secuencia de uno o más miembros iniciales.

C ++ 11 proporciona requisitos / permisos similares en §9.2 / 19:

Si una unión de diseño estándar contiene dos o más estructuras de diseño estándar que comparten una secuencia inicial común, y si el objeto de unión de diseño estándar actualmente contiene una de estas estructuras de diseño estándar, se permite inspeccionar la parte inicial común de cualquier de ellos. Dos estructuras de diseño estándar comparten una secuencia inicial común si los miembros correspondientes tienen tipos compatibles con el diseño y ninguno de los miembros es un campo de bits o ambos son campos de bits con el mismo ancho para una secuencia de uno o más miembros iniciales.

Aunque ninguno lo declara directamente, ambos tienen una fuerte implicación de que "inspeccionar" (leer) a un miembro está "permitido" solo si 1) es (parte de) el miembro escrito más recientemente, o 2) es parte de una inicial común secuencia.

Esa no es una declaración directa de que hacer lo contrario es un comportamiento indefinido, pero es lo más cercano a lo que sé.

Algo que aún no se menciona en las respuestas disponibles es la nota a pie de página 37 en el párrafo 21 de la sección 6.2.5:

Tenga en cuenta que el tipo agregado no incluye el tipo de unión porque un objeto con tipo de unión solo puede contener un miembro a la vez.

Este requisito parece implicar claramente que no debe escribir en un miembro y leer en otro. En este caso, podría ser un comportamiento indefinido por falta de especificación.

Bien explico esto con un ejemplo.
Supongamos que tenemos la siguiente unión:

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

Supongo que sizeof(int)da 4, y sizeof(short)da 2.
cuando escribes union A a = {10}bien, crea una nueva var de tipo A y pon el valor 10.

su memoria debería verse así: (recuerde que todos los miembros del sindicato obtienen la misma ubicación)

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

como puede ver, el valor de ax es 10, el valor de ay 1 es 10 y el valor de ay [0] es 0.

ahora, ¿qué pasaría si hago esto?

a.y[0] = 37;

nuestra memoria se verá así:

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

esto convertirá el valor de ax a 2424842 (en decimal).

ahora, si su unión tiene un flotante, o doble, su mapa de memoria puede ser más desordenado, debido a la forma en que almacena los números exactos. Más información puede obtener aquí .