C源包括名称长度

Question

按照C标准，子条款6.10.2，第5段[ISO/IEC 9899：2011]，

执行应提供由一个或多个的序列 独特映射非数字或数字（6.4.2.1）后跟 （。）和单个非数字。第一个字符不能是 数字。该实施可能会忽略字母顺序案例 的区别，并将该映射限制为在 时间段之前的八个重要字符。

这将意味着如果两个包含文件具有共同的前8个字符，则它实际选取的标头是未定义的。

当我使用clang或gcc编译时，我并没有真正面对这个问题。但是，在GCC和Clang中是否有源文件包含的记录行为？

在现代世界中，如果任何编译器真的限制为8个字符，我会觉得很奇怪。

参考：C11 WG14 draft version N1570，Cert C Coding standard

Answer 1

这意味着，如果两个包含文件有共同的前8个字符，它实际上采的头是不确定的。

不，我会反驳这：纵观确切措辞，我们看到标准的用途：

[..]实现可以忽略[..]

这是“可能”，而不是“应该”。如果使用后者，这确实意味着行为不明确（N1570 $ 4/2）。由于“可以”使用的原样，没有确切的声明，我认为它是安全的假设这个词的正常含义（source，重点煤矿）：

用来表达机会或许可

因此，一个实现允许只考虑前8个字符，但不一定。

有趣的事情：我找不到在GCC手册中的“序列”的“区别限”的确切文件，这意味着（N1570 $ 4/8，重点煤矿）...

的实现应附有一个文件，该文件定义了全部实现定义和特定于语言环境的特性和所有扩展。

......海湾合作委员会可以（根据一些非常迂腐的观点）被认为是不合格的实施。其手册的实际相关部分，如@PaulGriffiths指出的那样，可能是（source，点4中的列表）：

在显着的标识符或宏名称初始字符。

预处理器将所有字符视为重要。 C标准只要求前63位有意义。

关于评论：

[..]我实际上是试图评估是否因为我使用的是Linux平台上的这些编译器之一，这将只要咬我。 [..]

我真的怀疑这会永远（再次？）成为一个问题。