Lo "struct hack" è un comportamento tecnicamente indefinito?

Quello che sto chiedendo è il noto trucco "l'ultimo membro di una struttura ha lunghezza variabile". Funziona in questo modo:

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

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

A causa del modo in cui la struttura è disposta in memoria, siamo in grado di sovrapporre la struttura a un blocco più grande del necessario e trattare l'ultimo membro come se fosse più grande di quello 1 charspecificato.

Quindi la domanda è: questa tecnica è un comportamento tecnicamente indefinito? . Mi sarei aspettato che lo fosse, ma ero curioso di sapere cosa dice lo standard su questo.

PS: sono consapevole dell'approccio C99 a questo, vorrei che le risposte si attengano specificamente alla versione del trucco come elencato sopra.

Come dice la FAQ C :

Non è chiaro se sia legale o portatile, ma è piuttosto popolare.

e:

... un'interpretazione ufficiale ha ritenuto che non sia strettamente conforme allo standard C, sebbene sembri funzionare con tutte le implementazioni note. (I compilatori che controllano attentamente i limiti degli array potrebbero emettere avvisi.)

La logica alla base del bit "strettamente conforme" è nelle specifiche, sezione J.2 Comportamento non definito , che include nell'elenco dei comportamenti indefiniti:

• Un indice dell'array è fuori intervallo, anche se un oggetto è apparentemente accessibile con il pedice dato (come nell'espressione lvalue a[1][7]data la dichiarazione int a[4][5]) (6.5.6).

Il paragrafo 8 della sezione 6.5.6 Operatori additivi ha un'altra menzione che l'accesso oltre i limiti di matrice definiti non è definito:

Se sia l'operando puntatore che il risultato puntano a elementi dello stesso oggetto matrice, o uno dopo l'ultimo elemento dell'oggetto matrice, la valutazione non deve produrre un overflow; in caso contrario, il comportamento è indefinito.

Credo che tecnicamente sia un comportamento indefinito. Lo standard (probabilmente) non lo affronta direttamente, quindi rientra nella "o dall'omissione di qualsiasi definizione esplicita di comportamento". clausola (§4 / 2 di C99, §3.16 / 2 di C89) che dice che è un comportamento indefinito.

Il "discutibilmente" sopra dipende dalla definizione dell'operatore di indice di matrice. Nello specifico, si dice: "Un'espressione postfissa seguita da un'espressione tra parentesi quadre [] è una designazione con indice di un oggetto array". (C89, §6.3.2.1 / 2).

Puoi sostenere che "di un oggetto array" è stato violato qui (dato che stai scrivendo al di fuori dell'intervallo definito dell'oggetto array), nel qual caso il comportamento è (un po 'più) esplicitamente indefinito, invece che semplicemente indefinito per gentile concessione di nulla che lo definisca.

In teoria, posso immaginare un compilatore che esegue il controllo dei limiti di array e (ad esempio) interrompe il programma quando / se si tenta di utilizzare un indice fuori intervallo. In effetti, non so che esista una cosa del genere, e data la popolarità di questo stile di codice, anche se un compilatore cercasse di imporre gli indici in alcune circostanze, è difficile immaginare che qualcuno lo sopporterebbe in questo modo questa situazione.

Sì, è un comportamento indefinito.

Il rapporto sui difetti del linguaggio C # 051 fornisce una risposta definitiva a questa domanda:

L'idioma, sebbene comune, non è strettamente conforme

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

Nel documento C99 Rationale il Comitato C aggiunge:

La validità di questo costrutto è sempre stata discutibile. Nella risposta a un rapporto sui difetti, il Comitato ha deciso che si trattava di un comportamento indefinito perché la matrice p-> elementi contiene solo un elemento, indipendentemente dal fatto che lo spazio esista.

Quel modo particolare di farlo non è esplicitamente definito in nessuno standard C, ma C99 include la "struct hack" come parte del linguaggio. In C99, l'ultimo membro di una struttura può essere un "membro di array flessibile", dichiarato come char foo[](con qualunque tipo si desideri al posto di char).

Non è un comportamento indefinito , a prescindere da ciò che qualcuno, ufficiale o meno , dice, perché è definito dallo standard. p->s, tranne quando usato come lvalue, restituisce un puntatore identico a (char *)p + offsetof(struct T, s). In particolare, questo è un charpuntatore valido all'interno dell'oggetto malloc'd, e ci sono 100 (o più, a seconda delle considerazioni sull'allineamento) successivi indirizzi immediatamente successivi che sono validi anche come charoggetti all'interno dell'oggetto allocato. Il fatto che il puntatore sia stato derivato usando ->invece di aggiungere esplicitamente l'offset al puntatore restituito da malloc, cast to char *, è irrilevante.

Tecnicamente, p->s[0]è il singolo elemento chardell'array all'interno della struttura, i pochi elementi successivi (ad esempio p->s[1]attraverso p->s[3]) sono probabilmente byte di riempimento all'interno della struttura, che potrebbero essere corrotti se esegui l'assegnazione alla struttura nel suo insieme ma non se accedi semplicemente a singoli membri, e il resto degli elementi è spazio aggiuntivo nell'oggetto assegnato che sei libero di usare come preferisci, a condizione che tu obbedisca ai requisiti di allineamento (e charnon abbia requisiti di allineamento).

Se sei preoccupato che la possibilità di sovrapporsi con padding byte nella struttura possa in qualche modo richiamare i demoni nasali, potresti evitarlo sostituendo 1in [1]con un valore che assicuri che non ci sia riempimento alla fine della struttura. Un modo semplice ma dispendioso per farlo sarebbe creare una struttura con membri identici tranne nessun array alla fine, e usarla s[sizeof struct that_other_struct];per l'array. Quindi, p->s[i]è chiaramente definito come un elemento dell'array nella struct for i<sizeof struct that_other_structe come un oggetto char in un indirizzo che segue la fine della struct for i>=sizeof struct that_other_struct.

Modifica: in realtà, nel trucco sopra per ottenere la dimensione giusta, potresti anche dover mettere un'unione contenente ogni tipo semplice prima dell'array, per assicurarti che l'array stesso inizi con l'allineamento massimo piuttosto che nel mezzo del riempimento di qualche altro elemento . Ancora una volta, non credo che tutto ciò sia necessario, ma lo offro al più paranoico degli avvocati linguistici là fuori.

Modifica 2: la sovrapposizione con i byte di riempimento non è sicuramente un problema, a causa di un'altra parte dello standard. C richiede che se due strutture concordano in una sottosequenza iniziale dei loro elementi, è possibile accedere agli elementi iniziali comuni tramite un puntatore a entrambi i tipi. Di conseguenza, se struct Tfosse dichiarata una struttura identica a ma con un array finale più grande, l'elemento s[0]dovrebbe coincidere con l'elemento s[0]in struct T, e la presenza di questi elementi aggiuntivi non potrebbe influenzare o essere influenzata dall'accesso agli elementi comuni della struttura più grande utilizzando un puntatore a struct T.

Sì, è un comportamento tecnicamente indefinito.

Nota che ci sono almeno tre modi per implementare lo "struct hack":

(1) Dichiarare l'array finale con dimensione 0 (il modo più "popolare" nel codice legacy). Questo è ovviamente UB, poiché le dichiarazioni di array di dimensioni zero sono sempre illegali in C. Anche se si compila, il linguaggio non fornisce alcuna garanzia sul comportamento di qualsiasi codice che viola i vincoli.

(2) Dichiarare l'array con una dimensione legale minima - 1 (il tuo caso). In questo caso qualsiasi tentativo di prendere il puntatore p->s[0]e usarlo per l'aritmetica del puntatore che va oltre p->s[1]è un comportamento indefinito. Ad esempio, un'implementazione di debug può produrre un puntatore speciale con informazioni sull'intervallo incorporate, che intercetterà ogni volta che si tenta di creare un puntatore oltre p->s[1].

(3) Dichiarare l'array con una dimensione "molto grande" come 10000, per esempio. L'idea è che la dimensione dichiarata dovrebbe essere maggiore di qualsiasi cosa tu possa aver bisogno nella pratica reale. Questo metodo è privo di UB per quanto riguarda il raggio di accesso all'array. Tuttavia, in pratica, ovviamente, allocheremo sempre una minore quantità di memoria (solo quella realmente necessaria). Non sono sicuro della legalità di questo, cioè mi chiedo quanto sia legale allocare meno memoria per l'oggetto rispetto alla dimensione dichiarata dell'oggetto (assumendo che non abbiamo mai accesso ai membri "non allocati").

Lo standard è abbastanza chiaro che non è possibile accedere a cose oltre alla fine di un array. (e passare attraverso i puntatori non aiuta, poiché non ti è permesso nemmeno incrementare i puntatori oltre uno dopo la fine dell'array).

E per "lavorare in pratica". Ho visto l'ottimizzatore gcc / g ++ utilizzare questa parte dello standard generando così un codice sbagliato quando si incontra questo C. non valido.

Se un compilatore accetta qualcosa di simile

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

Penso che sia abbastanza chiaro che deve essere pronto ad accettare un pedice su "dat" oltre la sua lunghezza. D'altra parte, se qualcuno codifica qualcosa come:

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

e successivamente accede a somestruct-> dat [x]; Non penserei che il compilatore abbia alcun obbligo di utilizzare codice di calcolo dell'indirizzo che funzionerà con valori elevati di x. Penso che se si volesse essere davvero al sicuro, il paradigma corretto sarebbe più simile a:

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

e quindi eseguire un malloc di (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + desiderato_array_length) byte (tenendo presente che se desiderato_array_length è maggiore di LARGEST_DAT_SIZE, i risultati potrebbero non essere definiti).

Per inciso, penso che la decisione di vietare gli array di lunghezza zero sia stata sfortunata (alcuni dialetti più vecchi come Turbo C lo supportano) poiché un array di lunghezza zero potrebbe essere considerato come un segno che il compilatore deve generare codice che funzionerà con indici più grandi .