(uint64_t)-1 是否保证产生 0xffffffffffffffff？

Question

我知道，C 标准很好地定义了(unsigned)-1 必须产生 2^n-1，即。 e.一个无符号整数，其所有位都已设置。 (uint64_t)-1ll 也是如此。但是，我在 C11 标准中找不到指定如何解释 (uint64_t)-1 的内容。

那么，问题是：C 标准中是否有任何保证，以下哪项成立？

(uint64_t)-1 == (uint64_t)(unsigned)-1   //0x00000000ffffffff
(uint64_t)-1 == (uint64_t)(int64_t)-1    //0xffffffffffffffff

Answer 1

是的。请参阅 C11 6.3.1.3 有符号和无符号整数：

1当一个整数类型的值转换为_Bool以外的其他整数类型时，如果该值可以用新的类型表示，则不变。

2 否则，如果新类型是无符号的，则在新类型可以表示的最大值的基础上反复加减一，直到该值在新类型的范围内。⁶⁰⁾

3 否则，新类型是有符号的，值不能在其中表示；结果要么是实现定义的，要么引发实现定义的信号。

⁶⁰⁾ 规则描述的是数学值的算术运算，而不是给定类型表达式的值。

情况 2 适用，因此 -1 以 0x10000000000000000 为模减少为 0xffffffffffffffff。

Answer 2

表达式1 和-1 的类型为int。转换为uint64_t时，适用加减2ⁿ直到值在范围内的原则，所以结果总是2ⁿ-1，在这个n = 64的情况。因此，(uint64_t)-1 始终为 2⁶⁴-1..

表达式(int64_t)-1 的计算结果为-1，因此同样的推理适用于表达式(uint64_t)(int64_t)-1，它也总是计算为2⁶⁴-1。

另一方面，(unsigned)-1 是 unsigned int 类型的正值，可能是 2¹⁶-1, 2³²-1, 2⁶⁴-1 或其他各种值，具体取决于编译平台。这些值在转换为 uint64_t 时可能不会产生 2⁶⁴-1。

Answer 3

我猜你写的是(uint64_t)-1 而不是-1ULL，因为你不想假设unsigned long long 的大小？如果是这样，那很好。但是，还有一个尚未提及的替代方案（实际上并没有回答您的问题），但可以通过回避问题来省去很多担忧：

另一种选择

一个好习惯是始终使用UINT64_C(x) 而不是(uint64_t)x。这是在<stdint.h> 中定义的宏，它会根据需要自动附加U、UL 或ULL。因此，UINT64_C(-1) 解析为 -1U、-1UL 或 -1ULL，具体取决于您的目标。这保证始终正常工作。

类型转换的危险

请注意，(uint64_t)x 实际上通常甚至无法正常工作。例如，

(uint64_t)2147483648                // RISKY

在某些编译器上生成警告，因为值 2147483648 (2^31) 太大而无法放入 32 位整数，并且以下内容甚至无法远程工作：

(uint64_t)1000000000000000000       // RISKY

但是，如果您改用UINT64_C()，那么一切都是黄金：

UINT64_C(2147483648)                // GOOD

UINT64_C(1000000000000000000)       // GOOD

UINT64_C(-1)                        // GOOD

注意事项：

• _C 后缀代表“常数”。
• 在<stdint.h> 中，还有用于有符号和无符号值的 8 位、16 位和 32 位版本。
• 对于 –1 的特殊情况，您也可以只写UINT64_MAX。

Answer 4

这是一个可以用几行代码回答的问题。

#include <stdio.h>

main()
{
    int          x;
    unsigned int y;

    x = -1;
    printf("\n0x%08x", x);

    y = (unsigned int) -1;
    printf("\n0x%08x", y);

}

在 Eclipse/Microsoft C 编译器上运行此代码会产生：

0xffffffff
0xffffffff

一个类似的程序可以告诉你uint64_t 产生了什么。

最后，如果您了解计算机如何使用 2 的补码来添加数字，那么您就会明白，对于任意位数（8、32、64 等）的字，-1 始终是所有 ff 的每个字节字/双字等