Ist der "Struktur-Hack" technisch undefiniertes Verhalten?

Was ich frage, ist der bekannte Trick "Das letzte Mitglied einer Struktur hat eine variable Länge". Es geht ungefähr so:

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

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

Aufgrund der Art und Weise, wie die Struktur im Speicher angeordnet ist, können wir die Struktur über einen größeren als den erforderlichen Block legen und das letzte Element so behandeln, als wäre es größer als der 1 charangegebene.

Die Frage ist also: Ist diese Technik technisch undefiniertes Verhalten? . Ich würde das erwarten, war aber neugierig, was der Standard dazu sagt.

PS: Ich bin mir des C99-Ansatzes bewusst. Ich möchte, dass sich die Antworten speziell an die oben aufgeführte Version des Tricks halten.

Wie die C FAQ sagt:

Es ist nicht klar, ob es legal oder portabel ist, aber es ist ziemlich beliebt.

und:

... eine offizielle Interpretation hat festgestellt, dass es nicht streng mit dem C-Standard übereinstimmt, obwohl es unter allen bekannten Implementierungen zu funktionieren scheint. (Compiler, die die Array-Grenzen sorgfältig prüfen, geben möglicherweise Warnungen aus.)

Die Begründung für das "streng konforme" Bit befindet sich in der Spezifikation, Abschnitt J.2 Undefiniertes Verhalten , die in der Liste des undefinierten Verhaltens Folgendes enthält:

• Ein Array-Index liegt außerhalb des Bereichs, selbst wenn ein Objekt anscheinend mit dem angegebenen Index zugänglich ist (wie im lvalue-Ausdruck a[1][7]in der Deklaration int a[4][5]) (6.5.6).

In Abschnitt 8 von Abschnitt 6.5.6 Additive Operatoren wird erneut erwähnt, dass der Zugriff über definierte Array-Grenzen hinaus nicht definiert ist:

Wenn sowohl der Zeigeroperand als auch das Ergebnis auf Elemente desselben Arrayobjekts oder eines nach dem letzten Element des Arrayobjekts zeigen, darf die Auswertung keinen Überlauf erzeugen. Andernfalls ist das Verhalten undefiniert.

Ich glaube, dass es technisch gesehen undefiniertes Verhalten ist. Der Standard spricht ihn (wohl) nicht direkt an, so dass er unter das "oder durch das Weglassen einer expliziten Definition des Verhaltens" fällt. Klausel (§4 / 2 von C99, §3.16 / 2 von C89), die besagt, dass es sich um undefiniertes Verhalten handelt.

Das obige "wohl" hängt von der Definition des Array-Subskriptionsoperators ab. Insbesondere heißt es: "Ein Postfix-Ausdruck, gefolgt von einem Ausdruck in eckigen Klammern [], ist eine tiefgestellte Bezeichnung eines Array-Objekts." (C89, §6.3.2.1 / 2).

Sie können argumentieren, dass das "eines Array-Objekts" hier verletzt wird (da Sie außerhalb des definierten Bereichs des Array-Objekts abonnieren). In diesem Fall ist das Verhalten (ein kleines bisschen mehr) explizit undefiniert und nicht nur undefiniert mit freundlicher Genehmigung von nichts, was es ganz definiert.

Theoretisch kann ich mir einen Compiler vorstellen, der Array-Grenzen überprüft und (zum Beispiel) das Programm abbricht, wenn Sie versuchen, einen Index außerhalb des Bereichs zu verwenden. Tatsächlich weiß ich nicht, dass so etwas existiert, und angesichts der Popularität dieses Codestils ist es schwer vorstellbar, dass sich irgendjemand damit abfinden würde, selbst wenn ein Compiler unter bestimmten Umständen versucht hätte, Indizes durchzusetzen diese Situation.

Ja, es ist undefiniertes Verhalten.

Der C-Sprachfehlerbericht Nr. 051 gibt eine endgültige Antwort auf diese Frage:

Die Redewendung ist zwar üblich, aber nicht streng konform

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

Im C99-Begründungsdokument fügt der C-Ausschuss Folgendes hinzu:

Die Gültigkeit dieses Konstrukts war immer fraglich. In der Antwort auf einen Fehlerbericht entschied der Ausschuss, dass es sich um ein undefiniertes Verhalten handelt, da das Array p-> Elemente nur ein Element enthält, unabhängig davon, ob der Speicherplatz vorhanden ist.

Diese spezielle Vorgehensweise ist in keinem C-Standard explizit definiert, aber C99 enthält den "Struktur-Hack" als Teil der Sprache. In C99 kann das letzte Mitglied einer Struktur ein "flexibles Array-Mitglied" sein, das als char foo[](mit dem gewünschten Typ anstelle von char) deklariert ist .

Es ist kein undefiniertes Verhalten , unabhängig davon, was jemand, offiziell oder anderweitig , sagt, da es durch den Standard definiert ist. p->s, außer wenn es als l-Wert verwendet wird, wird zu einem Zeiger ausgewertet, der mit identisch ist (char *)p + offsetof(struct T, s). Dies ist insbesondere ein gültiger charZeiger innerhalb des malloc'd-Objekts, und unmittelbar darauf folgen 100 (oder mehr, abhängig von Ausrichtungsüberlegungen) aufeinanderfolgende Adressen, die auch als charObjekte innerhalb des zugewiesenen Objekts gültig sind . Die Tatsache, dass der Zeiger durch Verwenden ->von abgeleitet wurde, anstatt den Versatz explizit zu dem Zeiger hinzuzufügen, der von malloc, in den umgewandelt wurde char *, zurückgegeben wird, ist irrelevant.

Technisch gesehen p->s[0]ist das einzelne Element des charArrays innerhalb der Struktur, die nächsten paar Elemente (z. B. p->s[1]bis p->s[3]) sind wahrscheinlich Auffüllbytes innerhalb der Struktur, die beschädigt werden können, wenn Sie die Zuordnung zur Struktur als Ganzes durchführen, aber nicht, wenn Sie nur auf einzelne zugreifen Mitglieder und der Rest der Elemente sind zusätzlicher Speicherplatz im zugewiesenen Objekt, den Sie nach Belieben verwenden können, solange Sie die Ausrichtungsanforderungen erfüllen (und charkeine Ausrichtungsanforderungen haben).

Wenn Sie befürchten, dass die Möglichkeit einer Überlappung mit Auffüllbytes in der Struktur Nasen-Dämonen hervorrufen könnte, können Sie dies vermeiden, indem Sie das 1In [1]durch einen Wert ersetzen, der sicherstellt, dass am Ende der Struktur kein Auffüllen erfolgt. Eine einfache, aber verschwenderische Möglichkeit, dies zu tun, besteht darin, eine Struktur mit identischen Elementen außer keinem Array am Ende zu erstellen und s[sizeof struct that_other_struct];für das Array zu verwenden. Dann p->s[i]ist klar definiert als ein Element des Arrays in der Struktur für i<sizeof struct that_other_structund als ein char-Objekt an einer Adresse nach dem Ende der Struktur für i>=sizeof struct that_other_struct.

Bearbeiten: Bei dem obigen Trick, um die richtige Größe zu erhalten, müssen Sie möglicherweise auch eine Vereinigung mit jedem einfachen Typ vor das Array setzen, um sicherzustellen, dass das Array selbst mit maximaler Ausrichtung beginnt und nicht in der Mitte des Auffüllens eines anderen Elements . Auch hier glaube ich nicht, dass dies notwendig ist, aber ich biete es den paranoidesten Sprachanwälten da draußen an.

Bearbeiten 2: Die Überlappung mit Füllbytes ist aufgrund eines anderen Teils des Standards definitiv kein Problem. C erfordert, dass, wenn zwei Strukturen in einer anfänglichen Teilsequenz ihrer Elemente übereinstimmen, auf die gemeinsamen Anfangselemente über einen Zeiger auf einen der beiden Typen zugegriffen werden kann. Wenn daher eine Struktur struct Tdeklariert würde, die mit einem größeren endgültigen Array identisch ist, jedoch mit einem größeren endgültigen Array, s[0]müsste das Element mit dem Element s[0]in übereinstimmen struct T, und das Vorhandensein dieser zusätzlichen Elemente könnte den Zugriff auf gemeinsame Elemente der größeren Struktur nicht beeinflussen oder durch diesen beeinflusst werden mit einem Zeiger auf struct T.

Ja, es ist technisch undefiniertes Verhalten.

Beachten Sie, dass es mindestens drei Möglichkeiten gibt, den "Struktur-Hack" zu implementieren:

(1) Deklarieren des nachfolgenden Arrays mit der Größe 0 (die "beliebteste" Methode im Legacy-Code). Dies ist offensichtlich UB, da die Array-Deklarationen der Größe Null in C immer unzulässig sind. Selbst wenn sie kompiliert werden, übernimmt die Sprache keine Garantie für das Verhalten von Code, der gegen Einschränkungen verstößt.

(2) Deklarieren des Arrays mit minimaler zulässiger Größe - 1 (Ihr Fall). In diesem Fall ist jeder Versuch, einen Zeiger auf eine Zeigerarithmetik zu p->s[0]verwenden, die darüber hinausgeht, p->s[1]undefiniertes Verhalten. Beispielsweise kann eine Debugging-Implementierung einen speziellen Zeiger mit eingebetteten Bereichsinformationen erzeugen, der jedes Mal abgefangen wird, wenn Sie versuchen, einen Zeiger darüber hinaus zu erstellen p->s[1].

(3) Deklarieren des Arrays mit einer "sehr großen" Größe wie beispielsweise 10000. Die Idee ist, dass die deklarierte Größe größer sein soll als alles, was Sie in der Praxis benötigen könnten. Diese Methode ist hinsichtlich des Array-Zugriffsbereichs frei von UB. In der Praxis werden wir jedoch natürlich immer weniger Speicher zuweisen (nur so viel, wie wirklich benötigt wird). Ich bin mir nicht sicher, ob dies legal ist, dh ich frage mich, wie legal es ist, weniger Speicher für das Objekt zuzuweisen als die deklarierte Größe des Objekts (vorausgesetzt, wir greifen niemals auf die "nicht zugewiesenen" Mitglieder zu).

Der Standard ist ziemlich klar, dass Sie nicht auf Dinge neben dem Ende eines Arrays zugreifen können. (und das Übergehen von Zeigern hilft nicht, da Sie nach dem Ende des Arrays nicht einmal Zeiger nach einem inkrementieren dürfen).

Und für "Arbeiten in der Praxis". Ich habe gesehen, dass der gcc / g ++ - Optimierer diesen Teil des Standards verwendet und somit falschen Code generiert, wenn dieses ungültige C erfüllt wird.

Wenn ein Compiler so etwas akzeptiert

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

Ich denke, es ist ziemlich klar, dass es bereit sein muss, einen Index für 'dat' über seine Länge hinaus zu akzeptieren. Auf der anderen Seite, wenn jemand etwas codiert wie:

typedef struct {
  int was auch immer;
  char dat [1];
} MY_STRUCT;

und greift dann später auf somestruct-> dat [x] zu; Ich würde nicht glauben, dass der Compiler verpflichtet ist, Adressberechnungscode zu verwenden, der mit großen Werten von x funktioniert. Ich denke, wenn man wirklich sicher sein wollte, wäre das richtige Paradigma eher wie folgt:

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

und dann ein Malloc von (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + gewünschte_array_length) Bytes ausführen (wobei zu berücksichtigen ist, dass die Ergebnisse undefiniert sein können, wenn die gewünschte_Array_Länge größer als LARGEST_DAT_SIZE ist).

Übrigens denke ich, dass die Entscheidung, Arrays mit der Länge Null zu verbieten, unglücklich war (einige ältere Dialekte wie Turbo C unterstützen dies), da ein Array mit der Länge Null als Zeichen dafür angesehen werden kann, dass der Compiler Code generieren muss, der mit größeren Indizes funktioniert .