如何让 Xcode 8 C 预处理器忽略 #defines 中的 // 注释

Question

C 预处理器 (cpp) 似乎应该正确处理此代码：

#define A 1 // hello there

int foo[A];

我希望将A 替换为1。

发生的情况是A 被1 // hello there 替换，这导致cpp -std=c99 test.c 的以下输出：

# 1 "test.c"

int foo[1 // hello there];

这不是有效的 C 并且无法编译。

我怎样才能让cpp 执行正确的替换？

关于编译器的注意事项：在 mac 上使用最新（8.2.1，2016 年 12 月）Xcode 中的cpp，所以我怀疑这是由于编译器过时造成的。

Answer 1

令我惊讶的是，我可以在我的 Mac (macOS Sierra 10.12.2;Apple LLVM version 8.0.0 (clang-800.0.42.1)) 上使用 XCode cpp /usr/bin/cpp 重现该问题 — 但不能使用 GNU cpp (我调用它仅使用cpp)。

解决方法包括：

/usr/bin/gcc -E -std=c99 test.c

这使用clang 包装器gcc 来运行C 预处理器并正确处理版本。您可以添加一个-v 选项并查看它的运行情况；我没有看到它运行 cpp 本身（它运行 clang -cc1 -E 有很多其他信息）。

你也可以使用：

clang -E -std=c99 test.c

实际上是一回事。

您也可以安装 GCC 并使用它来代替 XCode。有一些关于如何完成的问题的答案（但它不适合胆小的人）。

Answer 2

请注意，// 不是有效的 C90 注释。它是在 C99 中引入的，因此请确保您的编译器和预处理器知道它们将使用 C99 标准。在许多情况下是-std=c99。 （这个问题已经被编辑清楚了）

---

接下来是我不相信预处理器关心 cmets。从 C99 规范的 6.10 开始，它显示了预处理器指令的语法，并且没有提到 cmets...

ANSI C 标准明确说明 cmets 应该在 2.1.1.2“翻译阶段”第 3 阶段（C99 中的 5.1.1.2）中被替换。 （取自this other answer）。

1. 源文件被分解为预处理标记和空白字符序列（包括 cmets）。源文件不应以部分预处理标记或部分注释结尾。 每条评论都被一个空格字符替换。 换行符被保留。除换行符之外的每个非空空白字符序列是保留还是替换为一个空格字符是由实现定义的。

较旧的工具可能没有遵循这一点，因为它们早于任何 C 标准，或者它们有错误，或者它们对标准的解释不同。他们可能保留了这些错误/怪癖以实现向后兼容性。使用clang -E -std=c99 与/usr/bin/cpp -std=c99 进行测试证实了这一点。尽管它们是同一个编译器，但它们的行为不同。

$ /usr/bin/cpp --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ ls -l /usr/bin/cpp
-rwxr-xr-x 1 root wheel 18240 Dec 10 01:04 /usr/bin/cpp
$ ls -l /usr/bin/clang
-rwxr-xr-x 1 root wheel 18240 Dec 10 01:04 /usr/bin/clang


$ /usr/bin/cpp -std=c99 test.c
# 1 "test.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 330 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "test.c" 2


int foo[1 // hello there];

$ /usr/bin/clang -E -std=c99 test.c
# 1 "test.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 331 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "test.c" 2


int foo[1];

我怀疑以/usr/bin/cpp 调用clang 会导致与cpp 的原始行为在行为不清楚时建立的错误/怪癖兼容。

我想这里的教训是使用cc -E 而不是cpp 来确保行为一致。

Answer 3

来自 C11 规范（已添加重点）：

5.1.1.2 翻译阶段

翻译的语法规则之间的优先级由 以下阶段⁶⁾.

1. [...] 多字节字符被映射 [...] 到源字符集 [...] 三元字符序列被替换 [...]

2. 每个反斜杠字符 () 的实例紧跟一个换行符都被删除，拼接物理源代码行 [...]

3. 源文件被分解为预处理标记和空白字符序列（包括 cmets）。 [...] 每条评论都替换为一个空格字符。 [...]

4. 执行预处理指令，扩展宏调用，并执行 _Pragma 一元运算符表达式。 [...]

注释 6) 指出：

实现应该表现得好像这些单独的阶段发生了一样，即使 尽管许多通常在实践中折叠在一起。源文件， 翻译单元，而翻译的翻译单元不需要 必须存储为文件，也不需要任何一对一 这些实体与任何外部表示之间的对应关系。 描述只是概念性的，并没有具体说明 具体实现。

因此，符合 C11 规范的实现不需要单独的预处理器。这意味着cpp 命令可以为所欲为。并且允许编译器驱动程序以任何它想要的方式执行阶段 1 到 3。所以预处理后获取输出的正确方法是使用cc -E调用编译器驱动。