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平臺上的這些編譯器之一，這將只要咬我。 [..]

我真的懷疑這會永遠（再次？）成爲一個問題。