「struct hack」は技術的に未定義の動作ですか？

私が尋ねているのは、よく知られている「構造体の最後のメンバーは可変長です」というトリックです。それはこのようなものになります：

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

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

構造体がメモリに配置される方法により、必要なブロックよりも大きい構造体に構造体をオーバーレイし、最後のメンバーを1 char指定されたものよりも大きいかのように扱うことができます。

だから問題は：この技術は技術的に未定義の動作ですか？。私はそれがそうであると期待しますが、標準がこれについて何を言っているのか興味がありました。

PS：私はこれに対するC99のアプローチを知っています。具体的には、上記のトリックのバージョンに忠実に答えてほしいと思います。

同様にC FAQは言います：

合法かポータブルかははっきりしないが、かなり人気がある。

そして：

...正式な解釈では、C規格に厳密に準拠していないと見なされていますが、既知のすべての実装で機能するようです。（配列の境界を注意深くチェックするコンパイラーは警告を発行する場合があります。）

「厳密に準拠する」ビットの背後にある理論的根拠は、仕様のセクションJ.2未定義の動作にあり、未定義の動作のリストに含まれています。

• （a[1][7]宣言された左辺値式のように）指定された添え字でオブジェクトにアクセスできるように見えても、配列添え字は範囲外ですint a[4][5]（6.5.6）。

セクション6.5.6のパラグラフ8には、定義された配列の境界を超えるアクセスは未定義であるという別の記述があります。

ポインターオペランドと結果の両方が同じ配列オブジェクトの要素を指している場合、または配列オブジェクトの最後の要素の1つ後を指している場合、評価によってオーバーフローは発生しません。それ以外の場合、動作は未定義です。

技術的には未定義の動作だと思います。標準は（おそらく）それを直接扱っていないため、「または動作の明示的な定義の省略」に該当します。未定義の動作であることを示す節（C99の§4/ 2、§89の§3.16/ 2）。

上記の「間違いなく」は、配列の添字演算子の定義に依存します。具体的には、「角かっこで囲まれた式が後に続くPostfix式[]は、配列オブジェクトの添え字付きの指定です。」（C89、§6.3.2.1/ 2）。

「配列オブジェクトの」がここで違反されていると主張することができます（配列オブジェクトの定義された範囲外で添え字を付けているため）。この場合、動作は（ほんの少し）単に未定義ではなく、明示的に未定義です。それを明確に定義するものはありません。

理論的には、配列の境界チェックを実行し、（たとえば）範囲外の添え字を使用しようとしたときにプログラムを中止するコンパイラを想像できます。実際、私はそのようなことが存在することを知りません。また、このスタイルのコードの人気を考えると、コンパイラーがある状況下で添え字を強制しようとしたとしても、誰かがそうすることに我慢するだろうとは想像しがたいです。この状況。

はい、それは未定義の動作です。

C言語の欠陥レポート＃051は、この質問に対する決定的な回答を提供します。

イディオムは一般的ですが、厳密に準拠していません

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

C99理論的根拠文書で、C委員会は以下を追加します。

この構造の妥当性は常に疑問視されてきました。委員会は、1つの欠陥レポートへの応答で、スペースの存在の有無に関係なく、配列p-> itemsには1つのアイテムしか含まれていないため、未定義の動作であると判断しました。

その特定の方法は、どのC標準でも明示的に定義されていませんが、C99には言語の一部として「struct hack」が含まれています。C99では、構造体の最後のメンバーはchar foo[]（柔軟な配列メンバー）として宣言できます（の代わりに任意の型を使用char）。

これは標準で定義されているため、公式または別の人の発言に関係なく、未定義の動作ではありません。p->s左辺値として使用される場合を除き、と同じポインタに評価されます(char *)p + offsetof(struct T, s)。特に、これはcharmallocされたオブジェクト内の有効なポインターでありchar、割り当てられたオブジェクト内のオブジェクトとしても有効な、それに続く100（またはそれ以上）の連続するアドレスが直後に続きます。ポインタが使用することによって導き出されたという事実->はなく、明示的で返されるポインタにオフセットを追加することmallocにキャストが、char *無関係です。

技術的にp->s[0]は、char構造体内の配列の単一の要素であり、次のいくつかの要素（例：p->s[1]からp->s[3]）は、構造体内のバイトにパディングしている可能性があり、構造全体への割り当てを実行すると破損する可能性がありますが、個々にアクセスするだけでは破損しませんメンバー、および残りの要素は、割り当てられたオブジェクトの追加のスペースであり、配置要件に従っている限り（配置要件charがない限り）、自由に使用できます。

構造体のパディングバイトとオーバーラップする可能性が何らかの理由で鼻の悪魔を呼び出すのではないかと心配している場合は、構造体の最後にパディングがないことを保証する値で1in [1]を置き換えることでこれを回避できます。これを行う単純で無駄な方法は、最後に配列がないことを除いて同一のメンバーで構造体を作成s[sizeof struct that_other_struct];し、配列に使用することです。次に、p->s[i]はstruct forの配列の要素として、i<sizeof struct that_other_structおよびstruct for の末尾に続くアドレスのcharオブジェクトとして明確に定義されていi>=sizeof struct that_other_structます。

編集：実際には、適切なサイズを取得するための上記のトリックでは、配列の前にすべての単純型を含む共用体を配置して、配列自体が他の要素のパディングの中央ではなく最大の配置で始まるようにする必要がある場合もあります。 。繰り返しになりますが、これが必要だとは思いませんが、私はそこにいる言語弁護士の最も偏執的な人のために提供しています。

編集2：標準の別の部分により、パディングバイトとの重複は問題にはなりません。Cは、2つの構造体がそれらの要素の最初のサブシーケンスで一致する場合、いずれかの型へのポインターを介して共通の初期要素にアクセスできることを要求します。結果として、同一の構造体であればstruct Tより大きな最終配列が宣言されたと、要素がs[0]要素と一致しなければならないs[0]でstruct T、これらの追加要素の存在は影響しなかったか、より大きな構造体の共通の要素にアクセスすることによって影響を受けることへのポインタを使用しますstruct T。

はい、技術的に未定義の動作です。

「struct hack」を実装するには少なくとも3つの方法があることに注意してください。

（1）サイズ0のトレーリング配列を宣言します（レガシーコードで最も一般的な方法）。ゼロサイズの配列宣言はCでは常に不正であるため、これは明らかにUBです。コンパイルしても、言語は制約違反コードの動作について保証しません。

（2）最小の正当なサイズで配列を宣言-1（あなたの場合）。この場合、ポインタを取得しp->s[0]てそれを超えるポインタ演算に使用しようとすると、p->s[1]動作は未定義になります。たとえば、デバッグ実装では、範囲情報が埋め込まれた特別なポインタを生成できます。これは、を超えてポインタを作成しようとするたびにトラップされますp->s[1]。

（3）たとえば、10000のような「非常に大きい」サイズで配列を宣言します。つまり、宣言されたサイズは、実際に必要なものよりも大きくなるはずです。この方法では、アレイのアクセス範囲に関してUBはありません。ただし、実際には、当然ながら、常に（実際に必要なだけの）少量のメモリを割り当てます。これの合法性についてはわかりません。つまり、オブジェクトの宣言されたサイズよりも少ないメモリをオブジェクトに割り当てることはどの程度合法なのでしょうか（「割り当てられていない」メンバーにアクセスしない場合）。

標準では、配列の末尾の横にあるものにアクセスできないことは明らかです。（そして、配列の終わりの後でポインターを1を超えてインクリメントすることもできないので、ポインターを経由しても効果がありません）。

そして「実際に働く」ために。gcc / g ++オプティマイザが標準のこの部分を使用しているため、この無効なCに遭遇すると誤ったコードが生成されるのを見てきました。

コンパイラが次のようなものを受け入れる場合

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

「dat」の添え字をその長さを超えて受け入れる準備ができている必要があることはかなり明白だと思います。一方、誰かが次のようなコードを書いた場合：

typedef struct {
  int何でも;
  char dat [1];
MY_STRUCT;

その後、後でsomestruct-> dat [x]にアクセスします。コンパイラーは、xの大きな値で機能するアドレス計算コードを使用する義務を負っていないと思います。本当に安全になりたいのであれば、適切なパラダイムは次のようになるでしょう。

#define LARGEST_DAT_SIZE 0xF000
typedef struct {
  int何でも;
  char dat [LARGEST_DAT_SIZE];
MY_STRUCT;

次に、（sizeof（MYSTRUCT）-LARGEST_DAT_SIZE + desired_array_length）バイトのmallocを実行します（desired_array_lengthがLARGEST_DAT_SIZEより大きい場合、結果が未定義になる可能性があることに注意してください）。

ちなみに、長さ0の配列はコンパイラがより大きなインデックスで動作するコードを生成する必要があるという印と見なすことができるため、長さ0の配列を禁止する決定は不幸なものであったと思います（Turbo Cなどの一部の古い方言はそれをサポートします）。 。