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

问题描述

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

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 它的操作数。这作为“|”的第二个按位操作数发生。

解决方法

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

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