Coverity 抱怨 htonl 操作數，但為什么呢？

Question

此代碼將本地切換轉換為傳出網絡命令 boolean（實際上是 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 的支持團隊，以便他們修復它。