¿El "truco de estructura" es un comportamiento técnicamente indefinido?

Lo que estoy preguntando es el conocido truco "el último miembro de una estructura tiene longitud variable". Es algo parecido a esto:

struct T {
    int len;
    char s[1];
};

struct T *p = malloc(sizeof(struct T) + 100);
p->len = 100;
strcpy(p->s, "hello world");

Debido a la forma en que la estructura se presenta en la memoria, podemos superponer la estructura sobre un bloque más grande de lo necesario y tratar el último miembro como si fuera más grande que el 1 charespecificado.

Entonces la pregunta es: ¿Es esta técnica un comportamiento técnicamente indefinido? . Esperaría que lo sea, pero tenía curiosidad por saber qué dice el estándar sobre esto.

PD: Soy consciente del enfoque C99 para esto, me gustaría que las respuestas se ajustaran específicamente a la versión del truco que se enumera anteriormente.

Como dice C FAQ :

No está claro si es legal o portátil, pero es bastante popular.

y:

... una interpretación oficial ha considerado que no se ajusta estrictamente al estándar C, aunque parece funcionar en todas las implementaciones conocidas. (Los compiladores que comprueban cuidadosamente los límites de la matriz pueden emitir advertencias).

La razón detrás del bit 'estrictamente conforme' está en la especificación, sección J.2 Comportamiento indefinido , que incluye en la lista de comportamiento indefinido:

• Un subíndice de matriz está fuera de rango, incluso si un objeto es aparentemente accesible con el subíndice dado (como en la expresión lvalue a[1][7]dada la declaración int a[4][5]) (6.5.6).

El párrafo 8 de la Sección 6.5.6 Operadores aditivos tiene otra mención de que el acceso más allá de los límites definidos de la matriz no está definido:

Si tanto el operando del puntero como el resultado apuntan a elementos del mismo objeto de matriz, o uno más allá del último elemento del objeto de matriz, la evaluación no producirá un desbordamiento; de lo contrario, el comportamiento no está definido.

Creo que técnicamente es un comportamiento indefinido. El estándar (posiblemente) no lo aborda directamente, por lo que se incluye "o por la omisión de cualquier definición explícita de comportamiento". cláusula (§4 / 2 de C99, §3.16 / 2 de C89) que dice que es un comportamiento indefinido.

El "posiblemente" anterior depende de la definición del operador de subíndice de matriz. Específicamente, dice: "Una expresión de sufijo seguida de una expresión entre corchetes [] es una designación subindicada de un objeto de matriz". (C89, §6.3.2.1 / 2).

Puede argumentar que el "de un objeto de matriz" está siendo violado aquí (ya que está subíndice fuera del rango definido del objeto de matriz), en cuyo caso el comportamiento es (un poquito más) explícitamente indefinido, en lugar de simplemente indefinido cortesía de nada que lo defina.

En teoría, puedo imaginar un compilador que verifica los límites de la matriz y (por ejemplo) abortaría el programa cuando / si intentara usar un subíndice fuera de rango. De hecho, no sé que exista algo así, y dada la popularidad de este estilo de código, incluso si un compilador intentara hacer cumplir los subíndices en algunas circunstancias, es difícil imaginar que alguien lo toleraría en esta situación.

Sí, es un comportamiento indefinido.

C Language Defect Report # 051 da una respuesta definitiva a esta pregunta:

El modismo, aunque es común, no se ajusta estrictamente

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_051.html

En el documento C99 Justificación, el Comité C agrega:

La validez de este constructo siempre ha sido cuestionable. En respuesta a un Informe de Defectos, el Comité decidió que se trataba de un comportamiento indefinido porque la matriz p-> elementos contiene solo un elemento, independientemente de que exista el espacio.

Esa forma particular de hacerlo no está definida explícitamente en ningún estándar de C, pero C99 incluye el "truco de estructura" como parte del lenguaje. En C99, el último miembro de una estructura puede ser un "miembro de matriz flexible", declarado como char foo[](con el tipo que desee en lugar de char).

No es un comportamiento indefinido , independientemente de lo que alguien, oficial o no , diga, porque está definido por el estándar. p->s, excepto cuando se usa como un lvalue, se evalúa como un puntero idéntico a (char *)p + offsetof(struct T, s). En particular, este es un charpuntero válido dentro del objeto malloc'd, y hay 100 (o más, dependiendo de las consideraciones de alineación) direcciones sucesivas inmediatamente después de él que también son válidas como charobjetos dentro del objeto asignado. El hecho de que el puntero se haya derivado usando en ->lugar de agregar explícitamente el desplazamiento al puntero devuelto por malloc, cast to char *, es irrelevante.

Técnicamente, si p->s[0]el elemento único de la charmatriz está dentro de la estructura, los siguientes elementos (por ejemplo, a p->s[1]través p->s[3]) probablemente sean bytes de relleno dentro de la estructura, que podrían corromperse si realiza una asignación a la estructura como un todo, pero no si simplemente accede a un individuo miembros, y el resto de los elementos son espacio adicional en el objeto asignado que puede usar libremente como quiera, siempre que obedezca los requisitos de alineación (y charno tenga requisitos de alineación).

Si le preocupa que la posibilidad de superposición con el acolchado de bytes de la estructura puede ser que de alguna forma de invocación demonios nasales, se podría evitar esta reemplazando la 1de [1]con un valor que asegura que no hay relleno al final de la estructura. Una forma simple pero inútil de hacer esto sería crear una estructura con miembros idénticos, excepto sin una matriz al final, y usarla s[sizeof struct that_other_struct];para la matriz. Entonces, p->s[i]se define claramente como un elemento de la matriz en la estructura para i<sizeof struct that_other_structy como un objeto char en una dirección que sigue al final de la estructura para i>=sizeof struct that_other_struct.

Editar: en realidad, en el truco anterior para obtener el tamaño correcto, es posible que también deba colocar una unión que contenga cada tipo simple antes de la matriz, para asegurarse de que la matriz en sí comience con una alineación máxima en lugar de en el medio del relleno de algún otro elemento . Una vez más, no creo que nada de esto sea necesario, pero se lo ofrezco al más paranoico de los abogados del lenguaje.

Edición 2: La superposición con bytes de relleno definitivamente no es un problema, debido a otra parte del estándar. C requiere que si dos estructuras coinciden en una subsecuencia inicial de sus elementos, se puede acceder a los elementos iniciales comunes mediante un puntero a cualquier tipo. Como consecuencia, si struct Tse declarara una estructura idéntica a, pero con una matriz final más grande, el elemento s[0]tendría que coincidir con el elemento s[0]en struct T, y la presencia de estos elementos adicionales no podría afectar o verse afectada al acceder a elementos comunes de la estructura más grande. usando un puntero a struct T.

Sí, es un comportamiento técnicamente indefinido.

Tenga en cuenta que hay al menos tres formas de implementar el "truco de estructura":

(1) Declarar la matriz final con tamaño 0 (la forma más "popular" en el código heredado). Obviamente, esto es UB, ya que las declaraciones de matriz de tamaño cero siempre son ilegales en C. Incluso si se compila, el lenguaje no ofrece garantías sobre el comportamiento de cualquier código que viole las restricciones.

(2) Declarar la matriz con un tamaño legal mínimo: 1 (su caso). En este caso, cualquier intento de tomar puntero ay p->s[0]usarlo para aritmética de puntero que vaya más allá p->s[1]es un comportamiento indefinido. Por ejemplo, se permite una implementación de depuración para producir un puntero especial con información de rango incrustada, que atrapará cada vez que intente crear un puntero más allá p->s[1].

(3) Declarar la matriz con un tamaño "muy grande" como 10000, por ejemplo. La idea es que se supone que el tamaño declarado es más grande que cualquier cosa que pueda necesitar en la práctica. Este método está libre de UB con respecto al rango de acceso a la matriz. Sin embargo, en la práctica, por supuesto, siempre asignaremos una menor cantidad de memoria (solo la realmente necesaria). No estoy seguro de la legalidad de esto, es decir, me pregunto qué tan legal es asignar menos memoria para el objeto que el tamaño declarado del objeto (asumiendo que nunca accedemos a los miembros "no asignados").

El estándar es bastante claro que no puede acceder a cosas al lado del final de una matriz. (y pasar por punteros no ayuda, ya que no se le permite incluso incrementar los punteros más allá de uno después del final de la matriz).

Y por "trabajar en la práctica". He visto el optimizador gcc / g ++ usando esta parte del estándar generando así un código incorrecto al cumplir con esta C.

Si un compilador acepta algo como

typedef struct {
  int len;
  char dat [];
};

Creo que está bastante claro que debe estar listo para aceptar un subíndice en 'dat' más allá de su longitud. Por otro lado, si alguien codifica algo como:

typedef struct {
  int lo que sea;
  char dat [1];
} MY_STRUCT;

y luego accede a alguna estructura-> dat [x]; No creo que el compilador tenga la obligación de utilizar un código de cálculo de direcciones que funcione con valores grandes de x. Creo que si uno quisiera estar realmente seguro, el paradigma adecuado sería más como:

#define LARGEST_DAT_SIZE 0xF000
typedef struct {
  int lo que sea;
  char dat [LARGEST_DAT_SIZE];
} MY_STRUCT;

y luego hacer un malloc de (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + deseada_array_length) bytes (teniendo en cuenta que si deseada_array_length es mayor que LARGEST_DAT_SIZE, los resultados pueden no estar definidos).

Por cierto, creo que la decisión de prohibir las matrices de longitud cero fue desafortunada (algunos dialectos más antiguos como Turbo C lo admiten) ya que una matriz de longitud cero podría considerarse como una señal de que el compilador debe generar código que funcione con índices más grandes. .