C23标准是否取消保留标识符？规则存疑寻求解答

C17标准7.1.3的保留标识符规则 #

• 以下划线开头且后跟大写字母或另一个下划线的标识符（除与关键字词法相同的），始终保留作任何用途
• 以下划线开头的标识符，始终保留作文件作用域的普通和标签命名空间标识符
• 同时存在“未来库方向”中定义的诸多特殊保留情况

C23标准7.1.3的保留标识符规则 #

C23对保留标识符规则进行了重构，核心以“潜在保留标识符”为基准：

• 所有由实现提供外部定义的潜在保留标识符（含“未来库方向”所列），保留作任何用途
• 实现不得为潜在保留标识符提供外部定义，除非该标识符明确被保留用于具有外部链接的用途
• 其他由实现提供的潜在保留标识符（含宏形式），仅在关联头文件被包含时保留作任何用途
• 未被上述规则覆盖的其余潜在保留标识符，均不被保留

注：C23的“未来库方向”内容与C17版本大致一致

C23 Annex J的矛盾问题 #

C23的附录J未同步更新，仍沿用C17时期的违规条款：

• (105) 程序声明或定义保留标识符（7.1.4允许的情况除外）属于违规行为
• (106) 程序移除以下划线开头且后跟大写字母或另一个下划线的宏定义属于违规行为

规则变更还是编辑失误？ #

这并非编辑失误，而是C23对保留标识符规则的实质性优化与重构：

1. C17采用的是基于命名格式的静态保留规则，直接通过标识符的下划线开头模式划定保留范围
2. C23转为基于实现行为的动态规则，将保留范围与“实现是否提供定义”“关联头文件是否被包含”绑定，逻辑更清晰，也更贴合实际使用场景
3. 附录J的滞后属于标准修订的正常现象——标准正文的优先级高于附录，附录J仅用于记录常见的可观测违规场景，后续版本大概率会同步更新附录内容以匹配正文规则
4. 原C17中两类下划线开头的标识符，在C23中被归类到“潜在保留标识符”，其保留状态不再由单纯的命名格式决定，而是取决于实现的具体提供情况

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