C++ GCC严格溢出

我们最近为一个大型代码库打开了

-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);
  }
}

我假设比较在

std:：find（）

中，并通过内联

Add（）

函数公开

---

我该如何解决这个问题？

是的，我读过其他的问题，没有什么帮助：

std:：在
std:：set
上查找

。答：GCC错误，关闭警告

重构条件

有符号整数的边格

---

我该怎么解决这个问题

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

一个接一个地获取它们（这就是为什么您首先启用它们，以检测可能发生溢出的位置，对吗？）

对于编译器正确的地方，应用更正

对于假阳性的地方，使用a在本地禁用警告-该#pragma的存在将意味着：“由于勤奋付出，我检查了，这里不会有东西溢出”

---

（可能会有帮助）

第一个问题的答案解释了为什么会发生这种情况，并提出了解决办法。正确而权威的答案是“不是很有帮助”？不知道你希望什么样的新信息会神奇地出现，仅仅因为你被问到了这个问题！“我该怎么解决这个问题？”——假设你已经理解了这个问题。你没有。你试图解决的问题根本不应该被视为问题，也不需要解决。您实际遇到的问题是使用编译器标志时，不了解它们的用途和用途，不了解它们的用途，对它们做出错误的假设，并且当您发现这些假设是错误的时，不愿意接受它们。这不是一个我们可以帮助您解决的技术问题。“关闭警告”并不能帮助我使用警告来发现真正的问题，所以不，不是很有帮助@哈，如果我明白了，我就不会问这个问题了。请指出我的错误假设；这将是对谈话的技术贡献，而不仅仅是对缺乏经验的尖刻抨击。@pdbj没有真正的问题。此警告选项并非仅用于指出实际问题。因为没有真正的问题，关闭警告是正确的做法。错误的假设在于此警告选项的用途。现在，您可能仍然希望查看数百条警告中的其余部分，以确定其他警告是否指向真正的问题，但这需要一些时间……感谢您的有用回复。是的，第一个，当然还有第二个。但是，对于第三个问题，请参阅我在23020208上的新评论：警告是由于呼叫站点的内容，而不是我的代码中的内容。所以我必须在每个由呼叫者触发的地方乱扔5行预处理器？恶心。@pdbj“恶心”我很同情。其他选项包括：“接受风险，关闭警告”或“寻找其他方法确保您的代码不会导致溢出-宏、模板等用于代码中-（因此不接受风险）并关闭警告”或“说服上司让实习生这样做，但不要关闭警告”

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)
    ^