GCC 严格溢出答案

【问题标题】：GCC strict-overflowGCC 严格溢出
【发布时间】：2016-09-10 00:40:34
【问题描述】：

我们最近为大型代码库启用了-Wstrict-overflow=5，并试图了解启用优化时出现的约 500 条警告。有些看起来是合法的，但有些事情是这样的：

std::vector<std::string> files;
...
void Add (const std::string file)
{
  if (std::find(files.begin(), files.end(), file) == files.end())
  {
    files.push_back(file);
  }
}

产生警告：

example.cc: In member function ‘void Add(std::string)’:
example.cc:465:8: error: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C2 -+ C1 [-Werror=strict-overflow]
void Add (const std::string file)
    ^

我假设比较在 std::find() 中，并通过内联 Add() 函数公开。

我应该如何解决这个问题？

是的，我已经阅读了其他 SO 问题，没有什么帮助：

23020208 std::find 在std::set 上。答：GCC bug，关闭警告

18521501重构条件

22798709 有符号整数的边缘情况

【问题讨论】：

第一个问题的答案解释了为什么会发生这种情况，并建议如何解决它。
正确权威的答案是“不是很有帮助”？仅仅因为您重新提出了问题，您不确定您期望哪些新信息会神奇地实现！
“我应该如何解决这个问题？” ——假设你已经理解了这个问题。你没有。您要解决的问题根本不应该被视为问题并且不需要解决。您实际遇到的问题是使用编译器标志而不了解它们的作用和预期用途，不了解它们的用途，对它们做出错误的假设，并且不愿意接受这些假设是错误的发现他们是。这不是我们可以帮助您解决的技术问题。
“关闭警告”并不能帮助我使用警告来发现真正的问题，所以不，不是很有帮助。 @hvd：呃，如果我理解了，我就不会问这个问题了。请指出我的错误假设；这将是对对话的技术贡献，而不仅仅是对缺乏经验的尖刻抨击。
@pdbj 没有真正的问题。此警告选项并非旨在仅指出实际问题。由于没有真正的问题，关闭警告是正确的做法。错误的假设在于此警告选项的用途。现在您可能仍想检查其余的数百个警告，以找出其他一些警告是否确实指向真正的问题，但这需要一段时间...

标签： c++ g++ gcc-warning

【解决方案1】：

我应该如何解决这个问题？

由于它们是由您无法控制的事物（即 gcc）引起的误报，因此您需要对其进行调整：

逐个处理（这就是您首先启用它们的原因，以检测可能发生溢出的位置，对吧？）
对于那些编译器正确的地方，应用更正
对于误报的地方，使用#pragma 在本地禁用警告 - 该#pragma 的存在将意味着：“尽职调查已付，我检查过，这里不可能溢出”。

（serenity prayer 可能会有所帮助）

【讨论】：

感谢您的有用回复。是的 1，当然 2。但是，对于 3，请参阅我对 23020208 的新评论：警告是由于呼叫站点上的东西，而不是我的代码。所以我必须在每个由调用者触发的地方乱扔 5 行预处理器？糟糕。
@pdbj “呸”我很同情。其他选项包括：“接受风险，关闭警告”或“寻找另一种方法来确保您的代码不会导致溢出 - 宏、模板等在您的代码中使用 - （因此不接受风险）并关闭警告”或“说服老板让实习生去做，不要关闭警告”