预处理器如何处理循环依赖？

在扩展预处理器宏时，不会扩展该宏的名称。因此，您的所有三个符号都被定义为它们自己：

ONE -> TWO -> THREE -> ONE (not expanded because expansion of ONE is in progress)
TWO -> THREE -> ONE -> TWO (        "                         TWO      "        )
THREE -> ONE -> TWO -> THREE (      "                         THREE    "        )

此行为由 C 标准的 §6.10.3.4 设置（C11 草案中的节号，尽管据我所知，该节的措辞和编号自 C89 以来没有变化）。当遇到宏名称时，将其替换为其定义（并处理 # 和 ## 预处理器运算符，以及类似函数的宏的参数）。然后重新扫描结果以获取更多宏（在文件其余部分的上下文中）：

2/ 如果在替换列表的扫描过程中找到被替换的宏的名称（不包括源文件的其余预处理标记），则不会替换它。此外，如果任何嵌套替换遇到被替换的宏的名称，它不会被替换……

该子句继续说，由于递归调用而未被替换的任何标记都被有效地“冻结”：它永远不会被替换：

…这些未替换的宏名称预处理标记不再可用于进一步替换，即使它们稍后（重新）在宏名称预处理标记将被替换的上下文中进行检查。

最后一句所指的情况在实践中很少出现，但这是我能想到的最简单的情况：

#define two one,two
#define a(x) b(x)
#define b(x,y) x,y
a(two)

结果是 one, two。 two 在替换 a 的过程中扩展为 one,two，扩展后的 two 被标记为完全扩展。随后，b(one,two) 被展开。这不再是在替换 two 的上下文中，而是 b 的第二个参数 two 已被冻结，因此不再展开。

---

出版物 ISO/IEC 9899:TC2 第 6.10.3.4 节“重新扫描和进一步替换”第 2 段回答了您的问题，为方便起见，我在此引用；以后，如果您对规范有任何疑问，请考虑阅读规范。

如果在替换列表的扫描过程中找到被替换的宏的名称（不包括源文件的其余预处理标记），则不会替换它。此外，如果任何嵌套替换遇到被替换的宏的名称，它不会被替换。这些未替换的宏名称预处理标记不再可用于进一步替换，即使它们稍后在该宏名称预处理标记将被替换的上下文中进行（重新）检查。

---

https://gcc.gnu.org/onlinedocs/cpp/Self-Referential-Macros.html#Self-Referential-Macros 回答了关于自引用宏的问题。

答案的关键是，当预处理器找到自引用宏时，它根本不会扩展它们。

我怀疑，相同的逻辑用于防止循环定义的宏的扩展。否则，预处理器将处于无限扩展中。

---

在您的示例中，您在定义同名变量之前进行宏处理，因此无论宏处理的结果是什么，您总是打印 1, 2, 3！

这是首先定义变量的示例：

#include <stdio.h>
int main()
{
    int A = 1, B = 2, C = 3;
#define A B
#define B C
//#define C A
    printf("%d\n", A);
    printf("%d\n", B);
    printf("%d\n", C);
}

这将打印 3 3 3。有点阴险的是，取消注释 #define C A 会改变行 printf("%d\n", B); 的行为

---

这是 rici's 和 Eric Lippert's 答案中描述的行为的一个很好的演示，即如果宏名称在已经扩展同一个宏时再次遇到，则不会重新扩展。

test.c 的内容：

#define ONE 1, TWO
#define TWO 2, THREE
#define THREE 3, ONE

int foo[] = {
  ONE,
  TWO,
  THREE
};

gcc -E test.c 的输出（不包括初始 # 1 ... 行）：

int foo[] = {
  1, 2, 3, ONE,
  2, 3, 1, TWO,
  3, 1, 2, THREE
};

（我会将此作为评论发布，但在评论中包含大量代码块有点尴尬，因此我将其作为社区 Wiki 答案。如果您觉得将其作为现有答案的一部分会更好，请随意复制它并要求我删除这个CW版本。）

---