我有一个奇怪的错误/错误/自我愚蠢问题。我正在用 C 语言开发一个小型应用程序，并且正在使用 Visual Studio 2010 SP1。违规代码：
uint64_t sum_squared_X = 65535*65535*64;
int64_t sum_squared_Y = 65535*65535*64;
调试时，我得到以下结果：
sum_squared_X = 18446744073701163072;
sum_squared_Y = -8388544;
问题是，为什么？uint64_t 的最大值为 2^64-1 或 18446744073709551615，int64_t 的最大值为 2^63-1 或 9223372036854775807。
65535*65535*64 = 274869518400，低于两个最大值。那为什么我会得到这些结果？
我在这里完全迷失了，我们将不胜感激。
简短回答：使用 32 位有符号算术将 65535 乘以 65535，得到 -131,071。然后将其乘以 -64 并转换为 uint64_t（由于环绕而创建更大的正值）或 int64_t（保留 -131,071 乘以 64 的结果）。
长答案：
无后缀整数十进制常量的类型取决于它的值。它是这个列表中第一个可以表示其值的：int、long int、long long int。（添加后缀或使用八进制或十六进制常量会更改列表。）因为这些类型取决于 C 实现，所以行为取决于 C 实现。
在您的机器中，int 很可能是 32 位。所以“65535”的类型是int，“64”的类型也是。
您的表达式以“65535*65535”开头。这将 65,535 乘以 65,535。数学结果是 4,924,836,225（十六进制，0xfffe0001）。对于 32 位有符号整数，这会溢出可表示的值。这是 C 标准中未定义的行为。在许多实现中通常发生的是值从 2 31 -1（最高可表示值）“环绕”到 -2 31（最低可表示值）。相同行为的另一种观点是，数学结果的位 0xfffe0001 被解释为 32 位有符号整数的编码。在二进制补码中，0xffffe0001 是 -131,071。
然后你的表达式乘以 64。-131,071*64 不会溢出；结果是 -8,388,544（编码为 0xff800040）。
最后，您使用结果来初始化 uint64_t 或 int64_t 对象。此初始化导致转换为目标类型。
int64_t 转换很简单；转换的输入是 -8,388,544，这在 int64_t 中完全可以表示，所以结果是 -8,388,544，编译器很可能通过扩展符号位（产生编码 0xffffffffff800040）来实现。
uint64_t 转换很麻烦，因为 -8,388,544 无法在 uint64_t 中表示。根据 1999 年 C 标准 6.3.1.3 2，“通过在新类型中可以表示的最大值的基础上反复加减一，直到该值在新类型的范围内。” 对于 uint64_t，“比新类型可以表示的最大值大一”是 2 64。所以结果是 -8,388,544 + 2 64，即 18,446,744,073,701,163,072。这也有编码 0xffffffffff800040。
对于从较窄宽度到较宽宽度的转换，这种比最大值加一的操作相当于将旧类型的符号位复制到新类型中的所有高位（符号扩展）。对于从更宽的宽度到更窄的宽度的转换，相当于丢弃了高位。在任何一种情况下，结果都是以 2 n为模的余数，其中 n 是新类型的位数。
When I compile your example, I clearly get an integer constant overflow warning for each of those lines. This is because the right side, the constants, is usually stored in a basic integer. You have to change the storage of those values to keep an overflow condition from happening. To fix this, do the following instead:
uint64_t sum_squared_X = (uint64_t)65535*65535*64;
int64_t sum_squared_Y = (uint64_t)65535*65535*64;
Read more here