El miembro de WG14, Jens Gustedt, dice en una publicación de blog sobre reglas estrictas de aliasing :
Las matrices de caracteres no deben reinterpretarse como objetos de otros tipos.
¿Es eso, de hecho, cierto? (Supongo que el idioma correspondiente en el estándar es la parte que dice que si un objeto tiene un tipo declarado, entonces ese tipo es su tipo efectivo). Si es así, ¿significa que un asignador que distribuye la memoria de una región de memoria declarada estáticamente? es inimplementable en el estándar C?
Sé que TeX ignora la mayor parte del sistema de tipos de Pascal y trata todo como una matriz de palabras debido a un problema similar, pero esperaba que si alguna vez me encontraba en una situación similar en ( malloc -less) C, podría simplemente declarar una máxima matriz de char y siga usando estructuras de la manera habitual. Tampoco veo cuál podría ser el punto de _Alignas en un mundo así, excepto como un dispositivo estandarizado para expresar requisitos no estándar (similar a volatile ).
Las reglas sobre aliasing se especifican en la sección 6.5p7 del estándar C :
Un objeto tendrá acceso a su valor almacenado solo mediante una expresión lvalue que tenga uno de los siguientes tipos: 88)
- un tipo compatible con el tipo efectivo del objeto,
- una versión calificada de un tipo compatible con el tipo efectivo del objeto,
- un tipo que es el tipo firmado o no firmado correspondiente al tipo efectivo del objeto,
- un tipo que es el tipo firmado o no firmado correspondiente a una versión calificada del tipo efectivo del objeto,
- un tipo de agregado o unión que incluye uno de los tipos antes mencionados entre sus miembros (incluido, recursivamente, un miembro de un subagregado o unión contenida), o
- un tipo de personaje.
- La intención de esta lista es especificar aquellas circunstancias en las que un objeto puede o no ser alias.
Tenga en cuenta que esta lista permite acceder a cualquier objeto a través de char * , pero no al revés, es decir, no se puede acceder a un objeto declarado como una matriz de uno o más caracteres como un lvalue de algún otro tipo.
Esto también significa que malloc no se puede implementar de manera compatible con el estándar, ya que no hay forma de crear memoria sin un tipo efectivo sin él. Sin embargo, malloc se considera parte de la implementación y, por lo tanto, puede aprovechar su conocimiento de los aspectos internos de la implementación para devolver un puntero a un bloque de memoria que puede usar un programa compatible.
La frase "Las matrices de caracteres no deben reinterpretarse como objetos de otro tipo" es imprecisa. Una declaración correcta es que si reinterpreta una matriz de caracteres como un objeto de otro tipo (excepto lo permitido por C 2018 6.5 7), el estándar C no define el comportamiento.
Como siempre, si queremos realizar una tarea y el estándar C no define el comportamiento que queremos, podemos buscar otras cosas para definir el comportamiento que queremos.
Si es así, ¿significa que un asignador que reparte memoria de una región de memoria declarada estáticamente no se puede implementar en C estándar?
Tal asignador no se puede implementar en C estrictamente conforme , que es un código C que no se basa en un comportamiento no especificado, indefinido o definido por la implementación (y no excede ningún límite mínimo de implementación). Es totalmente posible escribir tal asignador en conformidad con C, que es C con extensiones. Sencillamente, uno podría colocar las rutinas de asignación de memoria en un archivo fuente y compilarlas con un conmutador que admita la creación de alias de memoria como diferentes tipos. (Esta es una extensión, como el -fno-strict-aliasing de GCC). Luego, al compilar otros archivos fuente con compiladores comunes, el compilador no ve el tipo efectivo de memoria en el archivo fuente de asignación de memoria, por lo que no puede verse afectado por el hecho de que las rutinas de asignación de memoria utilizan matrices de caracteres. (Esta es otra extensión, aunque el comportamiento surge implícitamente de nuestra comprensión de cómo se diseñan los compiladores y los enlazadores).
El estándar claramente permite implementaciones que están destinadas a ser adecuadas para tareas que requieren grupos de memoria estática para ampliar la semántica del lenguaje para admitirlas, y permite que los programas "conformes" (pero no estrictamente conformes) exploten tales extensiones. De hecho, la gran mayoría de las implementaciones de C se pueden configurar para admitir tales tareas de manera mutuamente compatible. El estándar no requiere que las implementaciones o configuraciones que no están destinadas a ser utilizables para tales fines admitan tales construcciones. Las implementaciones que no son compatibles con las construcciones necesarias para acomodar grupos de memoria estática, casi por definición, no serían adecuadas para tareas que requieren grupos de memoria estática, pero el Estándar no intenta exigir que todas las implementaciones sean adecuadas para todos los propósitos.
En consecuencia, al escribir reglas sobre aliasing basado en tipos, los autores del estándar no ejercieron nada cercano al nivel de cuidado que habría sido apropiado si pretendieran que dichas reglas sirvieran como un límite entre los programas que deberían funcionar y los programas eso no debería Puede parecer extraño que las reglas del C99 que nunca han sido ni remotamente satisfactorias, como lo demuestra la confusión y la controversia que las rodea durante los últimos 20 años, hayan permanecido sin cambios, pero hay una razón simple para eso: cambiar las reglas requeriría llegar a un consenso. en cuanto a lo que se supone que deben decir, y sería imposible escribir un solo conjunto de reglas, adecuado para todos los propósitos, para distinguir entre operaciones que deben o no deben considerarse significativas, ya que la cuestión de si una implementación debe se espera que procese una construcción de manera significativa depende de los propósitos para los que está diseñada y configurada .
Cuando el estándar caracteriza una acción como "comportamiento indefinido" o como una violación de una restricción, significa ni más ni menos que el propio estándar no impone requisitos sobre cómo las implementaciones procesan el código en la situación relevante. El estándar no intenta distinguir las acciones que son claramente erróneas de aquellas que pueden no ser transferibles a todas las implementaciones imaginables, pero se debe esperar que se comporten de manera idéntica en el 99% de ellas. El estándar tampoco se esfuerza mucho por considerar todos los casos de esquina donde una acción que generalmente invocaría UB podría (y quizás debería) ser procesada de la misma manera significativa por todas las implementaciones.
El código que espera hacer cosas "raras" con la memoria debe procesarse utilizando configuraciones que lo permitan, incluso si el código es estrictamente conforme . Manejar todos los casos complicados en las reglas tal como están escritas requeriría optimizaciones anteriores que a menudo serían útiles, y tanto clang como gcc ignorarán esos casos difíciles en lugar de renunciar a las optimizaciones. La cuestión de si un fragmento de código se procesará de manera significativa depende mucho más de la configuración del compilador que de si el código pasa por todos los aros dados en el Estándar.