“结构骇客”在技术上是不确定的行为吗？

我要问的是众所周知的“结构的最后一个成员具有可变长度”的技巧。它是这样的：

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常见问题解答所说：

尚不清楚它是合法的还是可移植的，但它很受欢迎。

和：

...官方解释认为它并不严格符合C标准，尽管它似乎在所有已知的实现中都有效。（仔细检查数组范围的编译器可能会发出警告。）

“严格符合”位的基本原理在规范第J.2节“ 未定义的行为”中，其中包括未定义的行为列表：

• 即使对象显然可以使用给定的下标访问（如a[1][7]给出声明的左值表达式int a[4][5]）（6.5.6），数组下标也超出范围。

第6.5.6节的第8段又提到了未定义数组界限之外的访问是未定义的：

如果指针操作数和结果都指向同一数组对象的元素，或者指向数组对象的最后一个元素，则求值不应产生溢出；否则，行为是不确定的。

我认为从技术上讲这是未定义的行为。该标准（可以说）没有直接解决，因此属于“或遗漏了任何明确的行为定义”。条款（C99的第4/2条，C89的第3.16 / 2条）指出这是未定义的行为。

上面的“可以说”取决于数组下标运算符的定义。具体来说，它说：“后缀表达式后跟方括号[]是数组对象的下标名称。” （C89，§6.3.2.1/ 2）。

您可以争辩说这里违反了“数组对象”（因为您正在数组对象的定义范围之外下标），在这种情况下，行为（稍微多了）是显式未定义的，而不是未定义的没有任何东西可以完全定义它。

从理论上讲，我可以想象有一个编译器执行数组边界检查，并且（例如）在您尝试使用超出范围的下标时会中止程序。实际上，我不知道这种事情存在，并且鉴于这种代码风格的普及，即使编译器在某些情况下试图强制执行下标，也很难想象有人会忍受这种做法。这个情况。

是的，这是未定义的行为。

C语言缺陷报告＃051针对此问题给出了明确的答案：

这个习语虽然很常见，但并没有严格遵循

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

C委员会在C99基本原理文档中添加：

这种结构的有效性一直令人怀疑。在对一份缺陷报告的答复中，委员会认为这是未定义的行为，因为数组p-> item仅包含一项，而与是否存在空格无关。

任何C标准都没有明确定义这种特定的实现方式，但是C99确实包括了“ struct hack”作为该语言的一部分。在C99中，结构的最后一个成员可能是“柔性数组成员”，声明为char foo[]（用您想要的任何类型代替char）。

不管官方或其他人怎么说，这都不是未定义的行为，因为它是由标准定义的。p->s，除了用作左值时，其结果等于的指针(char *)p + offsetof(struct T, s)。特别是，这是charmalloc对象内部的有效指针，紧随其后的有100个（或更多，取决于对齐方式）连续地址，这些地址也可用作char已分配对象内部的对象。该指针是通过使用得到的事实->，而不是明确地将偏移到返回的指针malloc，转换为char *，是无关紧要的。

从技术上讲，它p->s[0]是char结构中数组的单个元素，接下来的几个元素（例如p->s[1]至p->s[3]）很可能在结构中填充字节，如果您对整个结构执行赋值，则可能会损坏这些字节，但如果仅访问单个结构，则不会损坏成员，其余元素是分配的对象中的附加空间，您可以随意使用，只要您遵守对齐要求（并且char没有对齐要求）即可。

如果担心结构中与填充字节重叠的可能性可能会以某种方式调用鼻恶魔，则可以通过将1in 替换为[1]确保结构末尾没有填充的值来避免这种情况。一种简单但浪费的方法是使用除了最后没有数组之外的相同成员来构造结构，并将其s[sizeof struct that_other_struct];用于该数组。然后，p->s[i]在for中明确定义为struct中数组的元素，并在struct i<sizeof struct that_other_struct末尾的地址处将其定义为char对象i>=sizeof struct that_other_struct。

编辑：实际上，在上述获取正确大小的技巧中，您可能还需要在数组之前放置一个包含每个简单类型的并集，以确保数组本身以最大对齐方式开始，而不是在其他元素的填充中间。再说一次，我不认为这是必要的，但是我将其提供给最偏执的语言律师。

编辑2：由于标准的另一部分，填充字节的重叠绝对不是问题。C要求，如果两个结构在其元素的初始子序列中一致，则可以通过指向任一类型的指针来访问公共的初始元素。因此，如果相同的结构struct T，但具有较大的阵列天线的最终被宣布，该元件s[0]将不得不与元件重合s[0]在struct T，并且这些附加的元件的存在不能影响或通过访问较大结构的共同要素的影响使用指向的指针struct T。

是的，这是技术上未定义的行为。

请注意，至少有三种方法可以实现“结构修改”：

（1）声明尾随数组，其大小为0（遗留代码中最“流行”的方式）。显然，这是UB，因为在C语言中零尺寸数组声明始终是非法的。即使它可以编译，该语言也不保证任何违反约束的代码的行为。

（2）声明最小合法大小的数组-1（您的情况）。在这种情况下，任何尝试获取指针p->s[0]并将其用于超出范围的指针算法的尝试p->s[1]都是未定义的行为。例如，允许调试实现产生带有嵌入式范围信息的特殊指针，该指针将在您每次尝试创建超出的指针时捕获p->s[1]。

（3）例如，声明大小为“ 10000 ”的“非常大”的数组。这个想法是声明的大小应该大于实际实践中可能需要的任何大小。就阵列访问范围而言，此方法没有UB。但是，在实践中，当然，我们总是会分配较少的内存（仅实际需要的数量）。我不确定这样做的合法性，即我想知道为对象分配比声明的对象大小少的内存是否合法（假设我们从不访问“未分配”成员）。

该标准非常清楚，您无法访问数组末尾之外的内容。（并且通过指针进行操作无济于事，因为您甚至不允许在数组结束后将指针增加到一个以上）。

并为“在实践中工作”。我已经看到gcc / g ++优化器使用了标准的这一部分，因此在遇到无效的C时会生成错误的代码。

如果编译器接受类似

typedef struct {
  英伦
  char dat [];
};

我认为很明显，必须准备接受超出其长度的“ dat”下标。另一方面，如果有人编写如下代码：

typedef struct {
  诠释什么；
  char dat [1];
} MY_STRUCT;

然后稍后访问somestruct-> dat [x]; 我认为编译器没有义务使用适用于x较大值的地址计算代码。我认为，如果您想真正地安全，那么正确的范例将更像是：

＃定义LARGEST_DAT_SIZE 0xF000
typedef struct {
  诠释什么；
  char dat [LARGEST_DAT_SIZE];
} MY_STRUCT;

然后执行（sizeof（MYSTRUCT）-LARGEST_DAT_SIZE + required_array_length）字节的malloc（请记住，如果desired_array_length大于LARGEST_DAT_SIZE，则结果可能不确定）。

顺便说一句，我认为禁止零长度数组的决定是一个不幸的决定（某些较早的方言，如Turbo C支持它），因为零长度数组可以被视为编译器必须生成可与较大索引一起工作的代码的标志。 。