Coverity 抱怨 htonl 操作数，但为什么呢？

Question

此代码将本地切换转换为传出网络顺序布尔值（实际上是 32 位 uint），并且至少有 10 年的历史，但 Coverity 最近才开始抱怨它。我不明白问题是什么以及它在哪里得到“操作数|”从。问题是 htonl 只适用于 32 位值，而我们有 16 位的 hton 吗？ 这是误检吗？

struct network_response_t {
    uint32_t exclusive;
}

bitmap16_t mode_t {
  TYPE_MIXED = 0x0,
  TYPE_EXCLUSIVE = 0x1,
  ...
}

mode_t local_mode;
network_response_t response;

response.exclusive = htonl((local_mode & TYPE_EXCLUSIVE) ? 1 : 0);

错误：

操作数不影响结果 (CONSTANT_EXPRESSION_RESULT) result_independent_of_operands: (__uint16_t)((__uint32_t)((local_mode & TYPE_EXCLUSIVE) ? 1 : 0) & 65535) >> 8 为 0 与值无关 的操作数。这作为“|”的按位第二个操作数出现。

Answer 1

这是误报。在 little-endian 平台上，htonl 执行 endian 交换，提取参数的字节并使用按位 OR 运算符以相反的顺序将它们重新组合在一起。 Coverity 正确地意识到其中一个字节将始终为零，因为在这种情况下原始参数始终为 0 或 1。但得出事实是无意的结论是错误的。

我建议将此问题报告给 Coverity 的支持团队，以便他们修复。