如果编译器定义了uu STDC_NO_VLA_uuuu，它还必须支持灵活的数组成员吗？

在C99中，灵活的数组成员（结构）和可变长度数组是符合标准的C99编译器（实现）必须同时支持的强制性部分

在C11中，允许实现定义（）：

\uuuu STDC\u NO\u VLA\uuu

整数常量1，用于指示 实现不支持可变长度数组或可变长度数组 修改类型

• 该定义是否意味着，指定不支持VLA的编译器也可以不支持这两种语言？或者，即使没有VLA支持，它也是强制性的

---

我在标准中没有发现任何地方规定带有FAM的结构是可变修改的类型，因此我认为即使不支持VLAs，也需要C11编译器来支持FAMs。有一项支持这种解释：具有FAM的结构的尺寸是固定的；FAM不算作大小的一部分（而VLA的大小不是编译时常量）。

灵活数组成员支持应独立于VLA支持。事实上，在C99标准通过在

struct

末尾声明零长度数组命名之前，可以使用灵活的数组成员

基本上，为了支持flexible数组成员，您需要做的唯一一件事就是更改编译器以支持

flexible[]

语法

相比之下，支持VLA需要付出更多的努力：

• 自动分配可能不再在编译时进行
• 必须更改

  sizeof

  运算符以支持运行时评估
• 必须设计特殊结构以保持阵列的大小可用

---

对于编译器设计者来说，这些实现点可能非常棘手，以至于他们决定不实现VLA。

好吧，很明显，标准没有说FAM是可选的，所以FAM不是可选的

---

不过，更进一步说，标准委员会似乎不太可能费心接受不支持FAMs的实现。与VLA相比，增加对灵活数组的支持是微不足道的——稍微调整一下解析器，允许结构的最后一个成员是大小为零的数组，然后到此为止。VLA需要更精细的静态分析，在一些微小的独立体系结构中可能会很繁重或不可能实现。

我不明白为什么VLA和灵活阵列成员的支持应该是相关的。@alk:我认为就标准而言，它们不相关，但它们都涉及在运行时确定大小的数组（正如许多使用

malloc（）

等）。我正要为VLA类型和具有FAM类型的结构的“类型大小”打印程序添加一些代码，我想知道

\uu STDC\u NO\u VLA\uu

是否意味着FAM代码应该不经过测试。只是出于病态的兴趣：您遇到过不支持灵活数组成员的现代C编译器吗？（我希望你没有，问题来自其他方面。）@NominalAnimal-没有，但我没有尝试过最近的Microsoft编译器。他们对C99（可能还有C11）的支持比旧版本更好，但我不确定他们离标准有多近，或者他们的宏定义声称的支持有多近。啊，没错。我更关注各种嵌入式C编译器。（正如我在其他讨论中提到的，我对MS编译器产品甚至未来版本的C标准不再抱有任何信任或希望。）C99之前的结构黑客技术通常涉及大小为1的数组。GCC可能允许大小为0的数组；JonathanLeffler：在C89之前，很多编译器都接受零大小数组，因为程序员使用零大小数组比破解1大小数组的怪癖更容易。C99增加的灵活数组成员无非是重新获得了一个本来就不应该被删除的功能。顺便说一句，我希望委员会有智慧只将具有VLA类型的声明对象作为可选功能，同时强制支持可变修改的类型。这将允许VLA的主要实际用途，即指向VLA的指针。@R。。完全同意。在我看来，这是C11的一个缺陷。指向VLA的指针是现代C编程中的一个重要特性。实际分配的VLA实例：不太多。@R..:IMHO，它们应该有一个三向宏来表示支持VLA实例、VLA类型但不支持实例，或者两者都不支持。即使目标平台在支持VLA类型方面没有特别的问题，向编译器添加支持也需要增加相当多的额外复杂性。如果一个编译器从来没有使用过任何需要VLA类型的程序，那么这种复杂性就完全是浪费。@R..：或者，换句话说，它支持一个可选功能，编译器的用户希望该功能被视为质量的标志，但对客户不关心的功能的支持不应该。指针指向VAL确实是一件非常“好的事情”。这并不能解决它的不足，但我很好奇为什么没有人在这里提到它？也许是作为一个穷人的替代品？