首页 > 解决方案 > Coverity 抱怨 htonl 操作数,但为什么呢?

问题描述

此代码将本地切换转换为传出网络顺序布尔值(实际上是 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,无论其操作数的值如何。这作为“|”的按位第二个操作数出现。

标签: c++cnetworkingcoverityhtonl

解决方案


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

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


推荐阅读