为什么 -INT_MIN 对于uint64_t类型不2147483648

Why -INT_MIN is NOT 2147483648 for uint64_t type

本文关键字：类型 2147483648 对于 -INT MIN 为什么 uint64      更新时间：2023-10-16

我了解p的结果。有人可以解释为什么up2 (uint64_t type) != 2147483648 但up (uint32_t type) == 2147483648 吗？

有人提到将 -INT_MIN 分配给无符号整数 up2 会导致溢出，但是

  1. -INT_MIN已经是一个正数，所以可以将其分配给uint64_t up2？

  2. 为什么将-INT_MIN分配给uint32_t up似乎是可以的？它产生正确的结果作为2147483648。

    #include <iostream>
#include <climits>
using namespace std;
int main() {
    int n = INT_MIN;
    int p = -n;
    uint32_t up = -n;
    uint64_t up2 = -n;
    cout << "n: " << n << endl;
    cout << "p: " << p << " up: " << up << " up2: " << up2 << endl;
    return 0;
}

    结果：

    n: -2147483648
p: -2147483648 //because -INT_MIN = INT_MIN for signed integer
up: 2147483648 //because up is unsigned int from 0 to 4,294,967,295 (2^32 − 1) and can cover 2147483648
up2: 18446744071562067968  //Question here. WHY up2 != up (2147483648)???

int p = -n;的行为在 2 的补码系统上是未定义的（接受你的问题中有错别字; INT_MAX在这样的系统上总是很奇怪），因为您溢出了int类型。所以你的整个程序是未定义的。

这就是为什么您看到INT_MIN在许多库中定义为-INT_MAX - 1的原因。

请注意，虽然由于有符号整数溢出而调用未定义的行为，但以下是您观察到的行为的最可能的解释：

如果系统上的int为 32 位，并且系统使用一个补码或二进制补码进行有符号整数存储，则符号位将扩展到 64 位无符号类型的高 32 位。

如果您以 base-16 打印出您的值，可能会更有意义。

n = 0x80000000
p = 0x80000000
up = 0x80000000
up2 = 0xFFFFFFFF80000000

你看到的是-n转换为uint64，其中溢出不是在 40 亿上，而是在 2**64 上：

18446744073709551616 - 2147483648 = 18446744071562067968

在您的情况下，表达式-n会导致未定义的行为，因为结果无法适应int数据类型的范围。（无论您是否将此未定义的结果分配给"更宽"类型的变量都无关紧要，反转本身是用int进行的。

试图解释未定义的行为是没有意义的。

相关文章：