Aliasing estricto en C++: qué es y cómo no dispararse en el pie

¿Qué es la regla de aliasing estricto y por qué tu código C++ puede romperse de repente?

¿Alguna vez has escrito código en C++ que parecía perfectamente correcto, pero el compilador con altos niveles de optimización (-O2 o -O3) lo convertía en algo que no funcionaba? Bienvenido al mundo del aliasing estricto (strict aliasing rule). Es una de las reglas más engañosas del lenguaje, que puede convertir la depuración en una verdadera odisea. En PythonLib nos encanta explicar temas complejos de forma sencilla, y el artículo de hoy no es una excepción.

Imaginemos: tienes dos punteros de diferentes tipos que apuntan a la misma área de memoria. El compilador, siguiendo la strict aliasing rule, tiene todo el derecho de decidir que no pueden referirse al mismo objeto. Y si violas esta regla, espera comportamiento indefinido (UB). El programa puede funcionar, puede fallar o puede mostrar resultados incorrectos. ¿Suena aterrador? Vamos a analizarlo.

La esencia de la regla: ¿por qué el compilador es tan "estricto"?

La strict aliasing rule en C++ (y C) establece: acceder a un objeto a través de un puntero o referencia de un tipo incompatible es UB. Las únicas excepciones son char, unsigned char y std::byte. ¿Por qué es necesario? La respuesta es simple: optimización. Si el compilador está seguro de que dos punteros de diferentes tipos no pueden apuntar a la misma memoria, puede reordenar operaciones, almacenar valores en caché en registros y optimizar el código agresivamente. Sin esta regla, el rendimiento de muchos programas se reduciría drásticamente.

Pero hay una desventaja: los desarrolladores que intentan hacer type punning (interpretar los mismos bytes como tipos diferentes) a menudo se encuentran con problemas. Un ejemplo clásico es intentar verificar rápidamente si un número de punto flotante es NaN mediante reinterpret_cast a int. El compilador puede "romper" dicho código.

¿Cómo se ve una violación de strict aliasing? Ejemplos de código

Consideremos el ejemplo más popular que circula de un Stack Overflow a otro:

#include <iostream>\n#include <cstdint>\n\nint main() {\n    float f = 3.14f;\n    // Violación de strict aliasing: leer float como int\n    int* pi = reinterpret_cast<int*>(&f);\n    std::cout << *pi; // UB!\n    return 0;\n}\n

A primera vista, es un truco común para ver la representación binaria de un float. Pero el estándar de C++ dice: float e int son tipos incompatibles. El compilador puede optimizar este código de manera que obtengas basura. Con optimizaciones activadas, GCC, por ejemplo, puede simplemente devolver algún valor conocido de antemano o incluso eliminar el código.

Otro ejemplo: trabajar con arreglos de bytes:

struct Point { int x, y; };\nchar buffer[sizeof(Point)];\n// Llenamos buffer...\nPoint* p = reinterpret_cast<Point*>(buffer);\np->x = 42; // UB, si buffer no fue creado como Point\n

Aquí la violación ocurre porque buffer es un arreglo de char, y lo estamos tratando como Point. Aunque char* puede apuntar a cualquier objeto, lo inverso no es cierto: Point* no puede apuntar a char[], a menos que la memoria haya sido asignada como Point.

Comparación de enfoques: ¿cómo evitar strict aliasing de forma segura?

Existen varias formas legales de realizar type punning en C++. Compararemos tres enfoques principales: memcpy, union y std::bit_cast (C++20). Cada uno tiene sus ventajas y desventajas.

1. memcpy — el viejo y confiable método

El método más seguro y portátil es copiar los bytes mediante memcpy. Los compiladores optimizan muy bien esta llamada, a menudo convirtiéndola en una simple carga de registro, por lo que no hay sobrecarga:

#inc