为什么C预处理器禁止宏拼接异常令牌？自研时能否移除该限制？

该限制的存在原因 #

首先要明确，这个校验并非GCC自定义的额外规则，而是C语言标准的强制要求：

• 符合C标准规范：现行C标准（C17 6.10.3.3 第3款）明确规定，##运算符对两个预处理令牌拼接后的结果必须是有效的预处理令牌，否则行为未定义。GCC的报错是对标准要求的合规实现，目的是把未定义行为转化为明确的编译错误，避免不可预期的后果。
• 错误定位更精准：预处理器阶段直接报错可以精准指向宏定义或者宏调用的位置，开发者一眼就能定位到是##拼接逻辑出了问题。如果把校验延后到编译阶段，报错信息只会指向宏展开后的代码行，没有宏展开上下文的情况下，开发者很难排查到问题根因是拼接操作。
• 保障预处理阶段逻辑一致性：C标准将编译流程拆分为多个有序阶段，预处理运行在第4阶段，所有处理对象都是第3阶段已经识别完成的合法预处理标识符、关键字、字面量、运算符等令牌。要求拼接结果为合法令牌，是为了保证预处理后续逻辑（比如宏替换、条件编译判断）的输入都是符合预期的合法结构，不会出现逻辑混乱。

去掉该限制的潜在隐患 #

你的设计虽然确实能带来少量灵活性，但隐患远大于收益：

• 不符合C标准兼容性：所有严格遵循C标准编写的代码，依赖该校验拦截非法拼接的逻辑都会失效，你实现的预处理器无法通过标准符合性测试，也无法正确编译大量依赖标准行为的现有C项目。
• 错误排查成本陡增：比如用户宏里写了#define JOIN(a,b) a##b，调用JOIN(x, +)的时候你不报错，等到编译阶段只会报类似syntax error before '+' token的通用语法错误，没有任何信息指向是宏拼接的问题，对不熟悉项目宏定义的开发者来说排查难度会提升数倍。
• 可能产生非预期的程序行为：举个极端例子，你拼接0x123和g，拼接结果0x123g不是合法的数字字面量，你的预处理器不报错，后续编译阶段可能会把它拆分为0x123和g两个令牌，原本想表达的单个数字直接变成了数字加标识符，程序逻辑完全走偏还不会报明显错误，这种隐性BUG极难定位。
• 你预期的性能收益几乎可以忽略：令牌合法性校验的逻辑非常简单，只是判断拼接后的字符串匹配哪种令牌的规则，对预处理器的整体性能影响不到1%，反而如果允许非法拼接，后续编译阶段处理异常令牌序列、输出更复杂的错误信息的开销会更高。

内容的提问来源于stack exchange，提问作者Edenia