c++ - 使用较新的编译器缩小转换错误

Question

我正在尝试在新系统上编译我的代码，但我的一个旧库突然遇到了麻烦。这是导致问题的代码的示例片段:

int main() {
    static const unsigned char pad_block[8] = {
    '\x80', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'};
}

我正在使用 g++ -o test main.cpp 编译它.我的旧系统使用 g++ 4.8.5，它在那里编译没有问题 - 甚至没有警告。在使用 g++ 7.5.0 的较新系统上，出现以下错误:

main.cpp: In function ‘int main()’:
main.cpp:3:67: error: narrowing conversion of ‘'\37777777600'’ from ‘char’ to ‘unsigned char’ inside { } [-Wnarrowing]
     '\x80', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'};

我一般理解缩小转换的问题，但我不明白这个特定情况。我的问题:

为什么突然出现这个问题，没有指定新的C++版本？

号码在哪里'\37777777600'来自？

我不想改变图书馆 - 有没有其他方法可以解决这个问题？

Answer 1

Why does this issue suddenly appear, without specifying a new C++ version?

您的问题与以下内容基本相同:

void foo(char x) {
    unsigned char y = {x};
}

这种在 C++11 中引入的语法对隐式转换应用了更严格的规则。然而，特定的 C++11 特性通过对数组应用这些更严格的规则，追溯性地改变了数组的花括号初始化的工作方式。这主要是因为它们看起来相似，否则会令人困惑。
由于引入了重大更改，从 GCC 5.0 开始，g++ 已开始将这些 C++11 故障报告为 C++03 代码中的警告，以简化转换。您可以在以下答案中找到更多详细信息: https://stackoverflow.com/a/28466553/4442671
另一个答案很好地涵盖了您的另外两个问题，但可以添加一点:

Where does the number '\37777777600' come from?

除了@AdrianMole 所说的，值得一提的是来自 '\0x80' 的这种转换。至 '\37777777600'似乎完全在 gcc 的报告过程内部，正如以下断言通过的事实所证明的那样。它需要 -std=c++11 ，但是您的代码会产生与它完全相同的错误，因此可以说它等效地适用。

static_assert(std::is_same<char, decltype('\x80')>::value, "");

I'd prefer not to change the library - is there another way around this?

如果库是单独编译的，添加 -Wno-narrowing其编译器选项将使错误消失而不触及代码，但是如果/当您更新库代码时，这确实存在隐藏更严重违规的风险。更改 char文字到 int文字是一个更好的全面修复，除非你需要做很多这样的事情并且维护补丁会很痛苦。显然，如果库没有上游源，那么这里没有理由不走重构之路。