É o comportamento “struct hack” tecnicamente indefinido?

O que estou perguntando é o conhecido truque "último membro de uma estrutura tem comprimento variável". É mais ou menos assim:

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

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

Por causa da forma como a estrutura é disposta na memória, podemos sobrepor a estrutura sobre um bloco maior do que o necessário e tratar o último membro como se fosse maior do que o 1 charespecificado.

Portanto, a questão é: essa técnica é um comportamento tecnicamente indefinido? . Eu esperava que sim, mas estava curioso para saber o que a norma diz sobre isso.

PS: Estou ciente da abordagem C99 para isso, gostaria que as respostas se prendessem especificamente à versão do truque, conforme listado acima.

Como diz o FAQ C :

Não está claro se é legal ou portátil, mas é bastante popular.

e:

... uma interpretação oficial considerou que não está estritamente em conformidade com o Padrão C, embora pareça funcionar em todas as implementações conhecidas. (Compiladores que verificam os limites da matriz cuidadosamente podem emitir avisos.)

A justificativa por trás do bit de 'conformidade estrita' está na especificação, seção J.2 Comportamento indefinido , que inclui na lista de comportamento indefinido:

• Um subscrito de array está fora do intervalo, mesmo se um objeto estiver aparentemente acessível com o subscrito fornecido (como na expressão lvalue a[1][7]dada a declaração int a[4][5]) (6.5.6).

O parágrafo 8 da Seção 6.5.6 Operadores aditivos menciona outra vez que o acesso além dos limites definidos da matriz é indefinido:

Se o operando de ponteiro e o resultado apontam para elementos do mesmo objeto de array, ou um após o último elemento do objeto de array, a avaliação não deve produzir um estouro; caso contrário, o comportamento é indefinido.

Acredito que tecnicamente seja um comportamento indefinido. O padrão (discutivelmente) não o aborda diretamente, então ele se enquadra no "ou pela omissão de qualquer definição explícita de comportamento." cláusula (§4 / 2 de C99, §3.16 / 2 de C89) que diz que é comportamento indefinido.

O "indiscutivelmente" acima depende da definição do operador de subscrito da matriz. Especificamente, ele diz: "Uma expressão pós-fixada seguida por uma expressão entre colchetes [] é uma designação subscrita de um objeto de matriz." (C89, §6.3.2.1 / 2).

Você pode argumentar que o "de um objeto de matriz" está sendo violado aqui (já que você está subscrevendo fora do intervalo definido do objeto de matriz), caso em que o comportamento é (um pouco mais) explicitamente indefinido, em vez de apenas indefinido cortesia de nada defini-lo completamente.

Em teoria, posso imaginar um compilador que faz a verificação de limites de array e (por exemplo) abortaria o programa quando / se você tentasse usar um subscrito fora do intervalo. Na verdade, não sei da existência de tal coisa, e dada a popularidade deste estilo de código, mesmo se um compilador tentasse impor subscritos em algumas circunstâncias, é difícil imaginar que alguém toleraria isso em essa situação.

Sim, é um comportamento indefinido.

O Relatório de defeito de linguagem C # 051 dá uma resposta definitiva a esta pergunta:

O idioma, embora comum, não é estritamente conforme

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

No documento de justificativa C99, o Comitê C adiciona:

A validade desse construto sempre foi questionável. Em resposta a um Relatório de Defeito, o Comitê decidiu que era um comportamento indefinido porque a matriz p-> itens contém apenas um item, independentemente da existência de espaço.

Essa maneira particular de fazer isso não está explicitamente definida em nenhum padrão C, mas C99 inclui o "hack de estrutura" como parte da linguagem. Em C99, o último membro de uma estrutura pode ser um "membro de matriz flexível", declarado como char foo[](com qualquer tipo que você deseja no lugar de char).

Não é um comportamento indefinido , independentemente do que alguém, oficial ou não , diga, porque é definido pela norma. p->s, exceto quando usado como um lvalue, é avaliado como um ponteiro idêntico a (char *)p + offsetof(struct T, s). Em particular, este é um charponteiro válido dentro do objeto malloc'd, e há 100 (ou mais, dependendo das considerações de alinhamento) endereços sucessivos imediatamente após ele, que também são válidos como charobjetos dentro do objeto alocado. O fato de que o ponteiro foi derivado usando em ->vez de adicionar explicitamente o deslocamento ao ponteiro retornado por malloc, convertido para char *, é irrelevante.

Tecnicamente, p->s[0]é o único elemento da charmatriz dentro da estrutura, os próximos elementos (por exemplo, p->s[1]através p->s[3]) são provavelmente bytes de preenchimento dentro da estrutura, que podem ser corrompidos se você executar a atribuição à estrutura como um todo, mas não se você simplesmente acessar um indivíduo membros e o resto dos elementos são espaço adicional no objeto alocado que você pode usar como quiser, desde que obedeça aos requisitos de alinhamento (e charnão tenha requisitos de alinhamento).

Se você está preocupado com a possibilidade de sobreposição com bytes de preenchimento na estrutura, de alguma forma, invocar demônios nasais, pode evitar isso substituindo o 1in [1]por um valor que garante que não haja preenchimento no final da estrutura. Uma maneira simples, mas inútil de fazer isso, seria fazer uma estrutura com membros idênticos, exceto nenhum array no final, e usar s[sizeof struct that_other_struct];para o array. Então, p->s[i]é claramente definido como um elemento da matriz na estrutura para i<sizeof struct that_other_structe como um objeto char em um endereço após o final da estrutura para i>=sizeof struct that_other_struct.

Edit: Na verdade, no truque acima para obter o tamanho certo, você também pode precisar colocar uma união contendo cada tipo simples antes da matriz, para garantir que a própria matriz comece com o alinhamento máximo, em vez de no meio do preenchimento de algum outro elemento . Novamente, eu não acredito que nada disso seja necessário, mas estou oferecendo isso para o mais paranóico dos advogados de línguas por aí.

Edição 2: A sobreposição com bytes de preenchimento definitivamente não é um problema, devido a outra parte do padrão. C requer que, se duas estruturas concordam em uma subsequência inicial de seus elementos, os elementos iniciais comuns podem ser acessados ​​por meio de um ponteiro para qualquer tipo. Como consequência, se uma estrutura idêntica a, struct Tmas com uma matriz final maior, fosse declarada, o elemento s[0]teria que coincidir com o elemento s[0]em struct T, e a presença desses elementos adicionais não poderia afetar ou ser afetada pelo acesso a elementos comuns da estrutura maior usando um ponteiro para struct T.

Sim, é um comportamento tecnicamente indefinido.

Observe que existem pelo menos três maneiras de implementar o "hack de estrutura":

(1) Declarando a matriz final com tamanho 0 (a forma mais "popular" em código legado). Isso é obviamente UB, uma vez que as declarações de array de tamanho zero são sempre ilegais em C. Mesmo que seja compilado, a linguagem não oferece garantias sobre o comportamento de qualquer código que viole as restrições.

(2) Declarando a matriz com tamanho mínimo legal - 1 (seu caso). Nesse caso, qualquer tentativa de pegar o ponteiro para p->s[0]e usá-lo para aritmética de ponteiro que vai além p->s[1]é um comportamento indefinido. Por exemplo, uma implementação de depuração tem permissão para produzir um ponteiro especial com informações de intervalo incorporadas, que será interceptado toda vez que você tentar criar um ponteiro além p->s[1].

(3) Declarar a matriz com tamanho "muito grande" como 10000, por exemplo. A ideia é que o tamanho declarado seja maior do que qualquer coisa que você possa precisar na prática. Este método não contém UB em relação ao intervalo de acesso à matriz. No entanto, na prática, é claro, sempre alocaremos uma quantidade menor de memória (apenas a quantidade realmente necessária). Não tenho certeza sobre a legalidade disso, ou seja, gostaria de saber o quão legal é alocar menos memória para o objeto do que o tamanho declarado do objeto (assumindo que nunca acessamos os membros "não alocados").

O padrão é bastante claro que você não pode acessar coisas além do final de um array. (e passar por ponteiros não ajuda, já que você não tem permissão nem mesmo para incrementar ponteiros após o fim do array).

E para "trabalhar na prática". Eu vi o otimizador gcc / g ++ usando essa parte do padrão, gerando código errado ao atender a este C. inválido

Se um compilador aceita algo como

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

Acho que está bem claro que deve estar pronto para aceitar um subscrito em 'dat' além de seu comprimento. Por outro lado, se alguém codifica algo como:

typedef struct {
  int tanto faz;
  char dat [1];
} MY_STRUCT;

e depois acessa somestruct-> dat [x]; Eu não acho que o compilador tem qualquer obrigação de usar código de computação de endereço que funcionará com grandes valores de x. Acho que se alguém quisesse estar realmente seguro, o paradigma adequado seria mais como:

#define LARGEST_DAT_SIZE 0xF000
typedef struct {
  int tanto faz;
  char dat [LARGEST_DAT_SIZE];
} MY_STRUCT;

e então faça um malloc de (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + desejado_array_length) bytes (tendo em mente que se o comprimento_de_matriz_desejado for maior que LARGEST_DAT_SIZE, os resultados podem ser indefinidos).

A propósito, acho que a decisão de proibir matrizes de comprimento zero foi infeliz (alguns dialetos mais antigos, como o Turbo C, suportam isso), uma vez que uma matriz de comprimento zero pode ser considerada um sinal de que o compilador deve gerar código que funcione com índices maiores .