C源包含名称长度

neo*_*org 13 c gcc clang

根据C标准,第6.10.2条第5款[ISO/IEC 9899:2011],

实现应为由一个或多个非数字或数字(6.4.2.1)组成的序列提供唯一映射,后跟一个句点(.)和一个非数字.第一个字符不应是数字.实现可以忽略字母大小写的区别,并在该句点之前将映射限制为八个重要字符.

这意味着如果两个包含文件共有前8个字符,那么它实际选择的标题是未定义的.

当我使用clang或gcc编译时,我并没有真正面对这个问题.但是,GCC和Clang中是否存在源文件包含的文档行为?

在现代世界中,如果任何编译器确实限制为8个字符,我会觉得很奇怪.

参考:C11 WG14草案版本N1570,证书C编码标准

Dan*_*our 6

这意味着如果两个包含文件共有前8个字符,那么它实际选择的标题是未定义的.

不,我反对这一点:看看我们看到标准使用的确切措辞:

[..]实施可能会忽略[..]

它是"可能",而不是" 应该 ".如果使用后者,那确实意味着行为未定义(N1570 $ 4/2).由于"may"原样使用,没有确切的声明,我认为可以安全地假设这个词的正常含义(来源,强调我的):

用于表达机会或许可

因此,允许实现仅考虑前8个字符,但它不必考虑.

有趣的是:我无法找到GCC手册中"序列"的"区别限制"的确切文档,意思是(N1570 $ 4/8,强调我的)...

实现附带一个文档,该文档定义所有已定义的实现和特定于语言环境的特征以及所有扩展.

......海湾合作委员会可以(在一些非常迂腐的观点下)被视为不合格的实施.正如@PaulGriffiths指出的那样,他们手册中实际相关的部分可能是(来源,列表中的第4点):

标识符或宏名称中的重要初始字符.

预处理器将所有字符视为重要字符.C标准仅要求前63个是重要的.

关于评论:

[..]我实际上试图评估,只要我在Linux平台上使用这些编译器之一,这是否会让我感到困惑.[..]

我真的怀疑这将永远(再次?)成为一个问题.