这个无括号的 C 预处理器定义安全吗？

Question

在我的/usr/include 目录中，至少有两个#define NULL 0 的变体是为C++ 代码量身定制的¹：

#define NULL 0    // from rpc/types.h
#define NULL (0)  // from libio.h

我觉得肯定有一个反例，第一个不安全，但我无法制作它。

否则，是否有一些令人信服的论据说明为什么在这种情况下不包括括号是安全的（例如，非正式的“正确性证明”）？

---

¹ 即不包括变体#define NULL ((void*)0)，这对C很有用，但在C++中无效。

Answer 1

我相信后者可能是由于 cargo-culting 而出现的，即始终将预处理器定义放在括号中的规则/反射。

Answer 2

没有区别。唯一具有较高优先级的运算符是::、++ 和--，它们不适用于0 和(0)。

我看到的唯一有趣的区别是混淆：

#define NULL (0)

void f(int x)
{
  // Do something with x
}

int main()
{
  f NULL; // This code compiles
  return 0;
}

Answer 3

如果我们谈论安全性，有人可能会争辩说 #define NULL 0 实际上比 #define NULL (0) 更安全。

你看，后者可以让你做这样的事情：a = func NULL; 而不是a = func(0);，它可以在任何在生产 C 代码中看到它的人的大脑中产生不受控制的核反应。这很不安全，你知道 =)

Answer 4

这是安全的，至少在没有意外的运算符优先级后果方面。

任何只是没有运算符的普通文字的宏定义总是安全的。比如……

#define FOO 1
#define NAME "Fred"
#define malloc my_malloc

Answer 5

由于还没有人明确说明...

关于为什么在这种情况下不包括括号是安全的，是否有一些令人信服的论据（例如，非正式的“正确性证明”）？

括号是一个分组结构。他们采用 expression 并将其转换为 primary-expression（使用标准语法中的名称）。一个完整的 primary-expression 不能被应用于它的运算符“触及”和拆分，无论该运算符的优先级如何。除了 cmets 中提到的函数调用和if 中提到的问题之外，这就是他们所做的一切；它们在宏中使用以确保扩展结果具有与源中相同的优先级（常量看起来像一个原子；primary-expression 的处理方式与表达式结构）。

数字0 是一个句法原子。由于是字面常量，它已经被定义为 primary-expression。表达式没有内部结构供运算符拆分，优先级问题甚至不适用。由于括号没有优先更改，因此将其包装在其中会将 primary-expression 转换为另一个 primary-expression，即它实际上什么都不做。

参考：C11 6.5.1 "Primary expressions"、C++11 5.1.1 "Primary expressions"。