c - 在 C 宏中，是否应该更喜欢 do { ... } while(0,0) 而不是 do { ... } while(0)？

Question

一位客户最近对我雇主的 C 代码库进行了静态分析，并向我们提供了结果。有用的补丁之一是更改著名的 do { ... } while(0) 的请求。 do { ... } while(0,0) 的宏。我明白他们的补丁在做什么(使用序列运算符 return 评估第二个“0”的值，所以效果是一样的)但不清楚他们为什么喜欢第二个在第一种形式上形成。

为什么人们应该更喜欢第二种形式的宏是否有合理的理由，或者我们客户的静态分析是否过于迂腐？

Answer 1

只是猜测他们为什么建议使用

do { ... } while(0,0)

结束

do { ... } while(0)

即使两者之间没有行为差异并且应该没有运行时成本差异。

我的猜测是静态分析工具提示 while 循环在更简单的情况下由常量控制，而在使用 0,0 时则不会。客户的建议可能只是为了让他们不会从该工具中得到一堆误报。

例如，我偶尔会遇到这样的情况，我希望有一个由常量控制的条件语句，但编译器会提示条件表达式计算为常量的警告。然后我必须克服一些困难让编译器停止提示(因为我不喜欢有虚假警告)。

你的客户的建议是我用来消除警告的方法之一，但在我的例子中它不是控制 while 循环，而是处理“总是失败”断言。有时，我会有一个永远不应该执行的代码区域(可能是开关的默认情况)。在那种情况下，我可能有一个断言总是失败并显示一些消息:

assert( !"We should have never gotten here, dammit...");

但是，至少我使用的一个编译器会发出一条关于表达式始终计算为 false 的警告。但是，如果我将其更改为:

assert( ("We should have never gotten here, dammit...", 0));

警告消失了，大家都很高兴。我猜想即使是您客户的静态分析工具也是如此。请注意，我通常会在宏后面隐藏一些跳圈 Action ，例如:

#define ASSERT_FAIL( x) assert( ((x), 0))

能够告诉工具供应商解决问题可能很好，但在某些合法情况下，他们实际上确实想要诊断由常量 bool 表达式控制的循环。更不用说即使您说服了工具供应商进行这样的更改，这对您明年或可能需要实际修复的时间也无济于事。