gcc 中将非保留标识符作为内置宏的原因是什么？

Question

今天，我偶然发现了一个相当有趣的编译器错误：

int main() {
  int const unix = 0; // error-line
  return unix;
}

使用 gcc 4.3.2 给出以下消息（是的，古老的......）：

error: expected unqualified-id before numeric constant

这绝对是相当令人困惑的。

幸运的是，clang (3.0) 有点帮助（像往常一样）：

error: expected unqualified-id
  int const unix = 0
            ^
<built-in>:127:14: note: expanded from:
#define unix 1
             ^

我当然没想到 unix 既不是用大写写的，也不是以下划线开头的，它是一个宏，尤其是一个内置的-合而为一。

我检查了 gcc 中的预定义宏，有 2 个（在我的平台上）使用“未保留”符号：

$ g++ -E -dM - < /dev/null | grep -v _
#define unix 1
#define linux 1

所有其他都是带有前导下划线的“行为良好”宏，使用传统的保留标识符，示例：（

#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1

#define __unix__ 1
#define __unix 1

#define __CHAR_BIT__ 8
#define __x86_64 1
#define __amd64 1
#define _LP64 1

这是一团糟，似乎没有任何特定的顺序...）

此外，还有很多“相似”的符号，所以我猜测存在向后兼容性的问题...

那么，unix在哪里和linux 宏来自于？

Answer 1

默认情况下，gcc 并不完全符合任何 C 标准。

使用 -ansi、-std=c99 或 -std=c1x 调用它，并且 unix 不会预定义的。 （-std=c1x 可能会成为 在未来更新的 gcc 版本中成为 -std=c11。）

有点令人困惑的是，这是在 GNU 预处理器的单独手册中记录的，而不是在 gcc 手册中。

引用 GNU 预处理器文档（info cpp，版本 4.5）：

C 标准要求所有系统特定宏都必须是
“保留的命名空间”。所有以两个下划线开头的名称，
或下划线和大写字母，为编译器保留
和图书馆，随心所欲地使用。然而，历史上
系统特定宏的名称没有特殊前缀；为了
例如，在 Unix 系统上定义“unix”是很常见的。为了
所有此类宏，GCC 提供了带有两个下划线的并行宏
添加在开头和结尾。如果定义了“unix”，
`__unix__' 也将被定义。永远不会超过两个
下划线； `_mips' 的平行项是 `__mips__'。

当“-ansi”选项或任何要求严格的“-std”选项时
一致性，被赋予编译器，所有系统特定的
保留命名空间之外的预定义宏将被抑制。这
保留命名空间内的并行宏保持定义。

我们正在慢慢淘汰所有超出范围的预定义宏
保留的命名空间。你永远不应该在新程序中使用它们，我们
鼓励您更正旧代码以使用并行宏
每当你找到它时。我们不建议您使用系统特定的
保留命名空间中的宏。最好是在
从长远来看，使用工具专门检查您需要的功能
例如“autoconf”。

当前版本的手册是 这里。