Tengo la siguiente estructura y función "captador" que devuelve a conversión a un entero sin signo:
struct s { uint32_t a; }; void get_a(struct s *st, unsigned *ret) { *ret = (unsigned)st->a; }Se ejecuta el siguiente código:
struct s st; uint16_t x; st.a = 1; get_a(&st, (unsigned *)&x); Y para x86_64, i686, armv7hl, ppc64le y otras arquitecturas x == 1 , pero para ppc64 x == 0 . ¿Por qué es esto? ¿Little-vs. big-endian?
El problema es que tienes:
uint16_t x; pero luego intenta escribir en esa ubicación de memoria como si fuera la ubicación de unsigned .
Si estaba en un sistema donde unsigned y uint16_t son del mismo tipo, está bien. Pero en otros sistemas, como el que usó para su ejemplo de código, tiene problemas.
En primer lugar, esto provoca un comportamiento indefinido al violar la regla estricta de creación de alias . Las variables de tipo uint16_t solo se pueden escribir a través de lvalues de tipo uint16_t o un tipo de carácter.
Pero incluso si no violara el alias estricto, aún causaría UB al escribir fuera de los límites de x . Probablemente, esté escribiendo 4 u 8 bytes en una ubicación de memoria de 2 bytes, por lo que desbordará el búfer.
También podría haber UB si x no está alineado correctamente para unsigned .