Se permite aliasing T* con char*. ¿También está permitido al revés?

Parte de su código es cuestionable debido a las conversiones de puntero involucradas. Tenga en cuenta que en esos casos reinterpret_cast<T*>(e) tiene la semántica de static_cast<T*>(static_cast<void*>(e)) porque los tipos que están involucrados son de diseño estándar. (De hecho, recomendaría que siempre use static_cast a través de cv void* cuando se trate de almacenamiento.)

Una lectura cercana del Estándar sugiere que durante una conversión de puntero hacia o desde T* se asume que realmente hay un objeto real T* involucrado which que es difícil de cumplir en algunos de sus fragmentos, incluso cuando 'hacer trampa' gracias a la trivialidad de los tipos involucrados (más sobre esto más adelante). Eso sería además del punto sin embargo porque...

El aliasing no se trata de conversiones de puntero. Este es el texto de C++11 que describe las reglas que comúnmente se conocen como reglas de 'alias estrictos', de 3.10 Lvalues y rvalues [basic.lval]:

10 Si un programa intenta acceder al valor almacenado de un objeto a través de glvalue de otro de los siguientes tipos el comportamiento es indefinido:

• el tipo dinámico del objeto,
• una versión calificada cv del tipo dinámico del objeto,
• un tipo similar (como se define en 4.4) al tipo dinámico del objeto,
• un tipo que es el tipo firmado o sin firmar correspondiente al tipo dinámico del objeto,
• un tipo que es el tipo firmado o sin firmar que corresponde a una versión tipo dinámico del objeto,
• un tipo agregado o de unión que incluye uno de los tipos antes mencionados entre sus elementos o miembros de datos no estáticos (incluido, recursivamente, un elemento o miembro de datos no estáticos de una subagregada o unión contenida),
• un tipo que es un tipo de clase base (posiblemente calificado por cv) del tipo dinámico del objeto,
• un tipo char o char sin signo.

(Este es el párrafo 15 de la misma cláusula y subcláusula en C++03, con algunos cambios menores en el texto con, por ejemplo, 'lvalue' que se utiliza en lugar de 'glvalue' ya que este último es una noción de C++11.)

A la luz de esas reglas, supongamos que una implementación nos proporciona magic_cast<T*>(p) que 'de alguna manera' convierte un puntero a otro tipo de puntero. Normalmente este sería reinterpret_cast, lo que produce resultados no especificados en algunos casos, pero como he explicado antes, esto no es así para los punteros a tipos de diseño estándar. Entonces es verdad que todos de sus fragmentos son correctos (sustituyendo reinterpret_cast por magic_cast), porque no hay glvalues involucrados en absoluto con los resultados de magic_cast.

Aquí hay un fragmento que aparece para usar incorrectamente magic_cast, pero que argumentaré que es correcto:

// assume constexpr max
constexpr auto alignment = max(alignof(int), alignof(short));
alignas(alignment) char c[sizeof(int)];
// I'm assuming here that the OP really meant to use &c and not c
// this is, however, inconsequential
auto p = magic_cast<int*>(&c);
*p = 42;
*magic_cast<short*>(p) = 42;

Para justificar mi razonamiento, asume este fragmento superficialmente diferente: {[47]]}

// alignment same as before
alignas(alignment) char c[sizeof(int)];

auto p = magic_cast<int*>(&c);
// end lifetime of c
c.~decltype(c)();
// reuse storage to construct new int object
new (&c) int;

*p = 42;

auto q = magic_cast<short*>(p);
// end lifetime of int object
p->~decltype(0)();
// reuse storage again
new (p) short;

*q = 42;

Este fragmento está cuidadosamente construido. En particular, en new (&c) int; se me permite usar &c a pesar de que c fue destruido debido a la reglas establecidas en el párrafo 5 de 3.8 Duración del objeto [básico.vida]. El párrafo 6 de same da reglas muy similares a las referencias al almacenamiento, y el párrafo 7 explica lo que sucede con las variables, punteros y referencias que solían referirse a un objeto una vez que su almacenamiento se reutiliza.Me referiré colectivamente a los como 3.8/5-7.

En este caso, &c se convierte (implícitamente) a void*, que es uno de los usos correctos de un puntero al almacenamiento que aún no se ha reutilizado. Similar p se obtiene de &c antes de que se construya el nuevo int. Su definición tal vez podría trasladarse a después de la destrucción de c, dependiendo de cuán profunda sea la magia de la implementación, pero ciertamente no después de la construcción int: el párrafo 7 se aplicaría y esta no es una de las situaciones permitidas. La construcción del objeto short también depende de que p se convierta en un puntero al almacenamiento.

Ahora, porque int y short son tipos triviales, no tengo que usar el llamadas explícitas a los destructores. Tampoco necesito las llamadas explícitas a los constructores (es decir, las llamadas a la colocación estándar habitual new declarada en <new>). Desde 3.8 Duración del objeto [básico.vida]:

1 [...] 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{[59]]}
• si el objeto tiene inicialización no trivial, su inicialización es completa.

La vida útil de un objeto de tipo T termina cuando:

• si T es un tipo de clase con un destructor no trivial (12.4), se inicia la llamada a destructor, o
• el almacenamiento que ocupa el objeto se reutiliza o libera.

Esto significa que puedo reescribir el código de manera que, después de plegar la variable intermedia q, termine con el fragmento original.

Ten en cuenta que p no se puede plegar. Es decir, los siguientes es definitivamente incorrecto:

alignas(alignment) char c[sizeof(int)];
*magic_cast<int*>(&c) = 42;
*magic_cast<short*>(&c) = 42;

Si asumimos que un objeto int está (trivialmente) construido con la segunda línea, entonces eso debe significar &c se convierte en un puntero al almacenamiento que ha sido reutilizado. Por lo tanto, la tercera línea es incorrecta although aunque debido a 3.8/5-7 y no debido a las reglas de aliasing estrictamente hablando.

Si no asumimos eso, entonces la segunda línea es una violación de las reglas de aliasing: estamos leyendo lo que en realidad es un objeto char c[sizeof(int)] a través de un glvalue de tipo int, que no es una de las excepciones permitidas. En comparación, *magic_cast<unsigned char>(&c) = 42; estaría bien (asumiríamos que un objeto short está construido trivialmente en la tercera línea).

Al igual que Alf, también recomendaría que haga uso explícito de la colocación Estándar new cuando use almacenamiento. Saltar la destrucción para los tipos triviales está bien, pero cuando se encuentra *some_magic_pointer = foo; es muy probable que se enfrente a una violación de 3.8 / 5-7 (no importa cuán mágicamente se obtuvo ese puntero) o de la reglas de aliasing. Esto significa almacenar el resultado de la nueva expresión, también, ya que lo más probable es que no pueda reutilizar el puntero mágico una vez que se construye su objeto due debido a 3.8/5-7 de nuevo.

Leer los bytes de un objeto (esto significa usar char o unsigned char) está bien, sin embargo, y ni siquiera debes usar reinterpret_cast ni nada mágico. static_cast a través de cv void* podría decirse que está bien para el trabajo (aunque siento que el Estándar podría usar algunas palabras mejores allí).