¿Está std::memcpy entre diferentes tipos copiables trivialmente un comportamiento indefinido?

Question 1

he estado usando std::memcpy evitar alias estricto por mucho tiempo.

Por ejemplo, inspeccionar un floatcomo esto:

float f = ...;
uint32_t i;
static_assert(sizeof(f)==sizeof(i));
std::memcpy(&i, &f, sizeof(i));
// use i to extract f's sign, exponent & significand

Sin embargo, esta vez, revisé el estándar, no encontré nada que valide esto. Todo lo que encontré es este:

Para cualquier objeto (que no sea un subobjeto potencialmente superpuesto) de tipo T copiable trivialmente, ya sea que el objeto tenga o no un valor válido de tipo T, los bytes subyacentes ([intro.memory]) que forman el objeto se pueden copiar en una matriz de char, char sin firmar o std::byte ([cstddef.syn]).⁴⁰ Si el contenido de esa matriz se vuelve a copiar en el objeto, el objeto conservará posteriormente su valor original.[Ejemplo:[ Example:
#define N sizeof(T)
char buf[N];
T obj;                          // obj initialized to its original value
std::memcpy(buf, &obj, N);      // between these two calls to std::memcpy, obj might be modified
std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
— fin del ejemplo]

y este:

Para cualquier tipo T copiable trivialmente, si dos punteros a T apuntan a objetos T distintos obj1 y obj2, donde ni obj1 ni obj2 son un subobjeto potencialmente superpuesto, si los bytes subyacentes ([intro.memory]) que forman obj1 se copian en obj2,⁴¹ obj2 tendrá posteriormente el mismo valor que obj1. [ Example:
T* t1p;
T* t2p;
// provided that t2p points to an initialized object ...
std::memcpy(t1p, t2p, sizeof(T));
// at this point, every subobject of trivially copyable type in *t1p contains
// the same value as the corresponding subobject in *t2p
— end example ]

Asi que, std::memcpying un float hacia/desde char[] está permitido, y std::memcpyTambién se permite intercambiar entre los mismos tipos triviales.

¿Está bien definido mi primer ejemplo (y la respuesta vinculada)? O la forma correcta de inspeccionar un float Es para std::memcpy en un unsigned char[] tampón y usando shiftarena ors para construir un uint32_t ¿de eso?

Nota: mirando std::memcpyLas garantías de pueden no responder a esta pregunta. Hasta donde yo sé, podría reemplazar std::memcpy con un simple ciclo de copia de bytes, y la pregunta será la misma.

Question 2

Es posible que el estándar no diga correctamente que esto está permitido, pero es casi seguro que se supone que lo está y, según mi leal saber y entender, todas las implementaciones tratarán esto como un comportamiento definido.

Para facilitar la copia en un formato real char[N] objeto, los bytes que componen el f Se puede acceder al objeto como si fuera un char[N]. Esta parte, creo, no está en disputa.

bytes de un char[N] que representan un uint32_t el valor se puede copiar en un uint32_t objeto. Esta parte, creo, tampoco está en disputa.

Igualmente indiscutible, creo, es que, por ejemplo, fwrite puede haber escrito los bytes en una ejecución del programa, y fread puede haberlos vuelto a leer en otra ejecución, o incluso en otro programa por completo.

Debido a esa última parte, creo que no importa de dónde provengan los bytes, siempre que formen una representación válida de algunos uint32_t objeto. Tú pudo han recorrido todo float valores, usando memcmp en cada uno hasta que obtuviste la representación que querías, que sabías que sería idéntica a la del uint32_t valor que está interpretando como. Tú pudo incluso haber hecho eso en otro programa, un programa que el compilador nunca ha visto. Eso hubiera sido válido.

Si desde la perspectiva de la implementación, su código es indistinguible de un código inequívocamente válido, su código debe verse como válido.

Question 3

¿Está bien definido mi primer ejemplo (y la respuesta vinculada)?

El comportamiento no está indefinido (a menos que el tipo de destino tenga representaciones de captura^† que no son compartidos por el tipo de origen), pero el valor resultante del entero está definido por la implementación. El estándar no garantiza cómo se representan los números de punto flotante, por lo que no hay forma de extraer la mantisa, etc., del entero de forma portátil; dicho esto, limitarse al uso de sistemas IEEE 754 no lo limita mucho en estos días.

Problemas de portabilidad:

IEEE 754 no está garantizado por C++
No se garantiza que el byte endian de float coincida con el entero endian.
(Sistemas con representaciones trampa^†).

Puedes usar std::numeric_limits::is_iec559 para verificar si su suposición sobre la representación es correcta.

^† Aunque, parece que uint32_t no puede tener trampas (ver comentarios) por lo que no debe preocuparse. Mediante el uso uint32_tya ha descartado la portabilidad a sistemas esotéricos: no se requieren sistemas conformes con el estándar para definir ese alias.

Question 4

Su ejemplo está bien definido y no rompe el alias estricto. std::memcpy dice claramente:

copias count bytes del objeto apuntado por src al objeto apuntado por dest. Ambos objetos se reinterpretan como matrices de
unsigned char.

El estándar permite aliasing de cualquier tipo a través de un (signed/unsigned) char* o std::byte y por lo tanto su ejemplo no exhibe UB. Sin embargo, si el número entero resultante tiene algún valor, es otra cuestión.

use i to extract f's sign, exponent & significand

Sin embargo, esto no está garantizado por la norma ya que el valor de un float está definido por la implementación (aunque en el caso de IEEE 754 funcionará).

¿Ha sido útil esta solución?