Question

我具有以下C代码片段，并在Clang中启用了-Wconversion：

uint8_t num_ch = get_num_channels();
uint64_t test_mask = 1 << num_ch;

我希望这样做会发出某种警告，因为1是隐式的“ signed int”，然后被分配给uint64_t，但编译器没有抱怨：（

我想念什么？

Answer 1

为什么没有类型转换警告？

简短的回答：由于您使用的clang / LLVM版本存在缺陷（有些人甚至称其为错误）。

讨论/解释/理由

问题源于对移位表达式s << u的求值，其中s是 signed 整数类型，而u是 unsigned 类型。现在，根据this C11 Draft Standard（正在轰动我）：

6.5.7按位移位运算符
...
3对每个操作数执行整数提升。结果的类型是升级后的向左操作数。

这表示表达式的结果是一个有符号整数。从今以后，我应该指出，我正在使用（并假设）一个使用32位'basic'int类型的平台。另请注意，不带后缀u的整数常量是 signed 类型。

注意：尽管我无权访问OP的嵌入式系统，也无权访问本地GCC编译器，但是我仍然可以使用以下版本中提供的 clang-cl 编译器重现该问题：最新版本的Visual Studio 2019（16.7.2-当我发现clang版本是什么时，我将添加clang版本）。

以下代码确实会生成预期的警告（实际上是两个警告，如图所示）：

#include <stdio.h>
#include <stdint.h>

int main()
{
    uint64_t test_mask = 1 << (uint8_t)(31); // Warnings here, as expected.
    printf("%016llX\n", test_mask);
    return 0;
}

警告：

警告：带符号的移位结果（0x80000000）设置符号的符号位转换表达式的类型（'int'）并变为负数 [-Wshift-sign-overflow]
警告：隐式转换更改签名：“ int”到“ uint64_t”（又名“ unsigned long long”） [-Wsign转换]

此外，printf调用的输出为FFFFFFFF80000000，这表明警告很重要的原因：位移（在32位int上）产生负值值，然后将其提升为64位时将其符号扩展-从而“破坏”预期/预期的结果（如果将文字0000000080000000仅更改为1，则其将1u ，从而避免了符号扩展）。

但是！如果对非常次要（有些甚至可能说不起眼的）进行了更改，则将位移的原义（常量）右手操作数更改为< em>完全等效变量，如下面的代码所示，然后来自 clang-cl 的警告消失（但输出仍然“损坏”-因此执行的操作相同）。

int main()
{
    uint8_t num_ch = 31;
    uint64_t test_mask = 1 << num_ch; // No warning here!
    printf("%016llX\n", test_mask);
    return 0;
}

可能不是最有用的答案-但是除了向LLVM的人员报告问题以外，还可以做更多的事情？我会绝对地提交这样的报告，因为由OP发布的代码可能会导致一些严重的问题，应该由启用了完整警告的编译器检测并指示（MSVC甚至对第二个代码段也发出警告。

为什么没有类型转换警告？

1 个答案: