有人能够解释一下以下代码的输出吗：
void myprint(unsigned long a)
{
printf("Input is %lx\n", a);
}
int main()
{
myprint(1 << 31);
myprint(0x80000000);
}
使用 gcc main.c 命令可以输出：
Input is ffffffff80000000
Input is 80000000
为什么 (1 << 31) 被视为有符号的，而 0x80000000 则被视为无符号的？
1是一个int（有符号），因此1 << n也是int。
0x80000000的类型（包括符号）由规则here确定，并且它取决于您的系统上int和其他整数类型的大小，您尚未指定。选择一种类型，使得0x80000000（一个大的正数）在该类型的范围内。0x80000000是一个大的正数。人们有时会错误地将其等同于负数，混淆值与表示。0x80000000的有符号性。你对它唯一的操作是将其传递给接受unsigned long参数的函数。因此，它是有符号还是无符号并不重要；当传递给转换函数时，它将被转换为具有相同值的unsigned long。（由于0x80000000在unsigned long的最小保证范围内，不存在超出范围的可能性）。0x80000000的问题。那么1 << 31呢？如果您的系统具有32位int（或更窄），由于带符号算术溢出，这会导致未定义行为（进一步阅读链接）。如果您的系统具有较大的int，则此代码将生成与0x80000000行相同的输出。1u << 31，并且您的系统具有32位int，则没有未定义行为，并且可以保证看到程序两次输出80000000。
由于您的输出不是80000000，因此我们可以得出结论，您的系统具有32位（或更窄）int，并且您的程序实际上会导致未定义的行为。如果int是32位，则0x80000000的类型将为unsigned int，否则为unsigned long。
flags &= ~0x0000000040000000;或清除第32位比特的代码flags &= ~0x0000000100000000;，则可能会出现问题。在任一情况下，最明显的逻辑修改flags &= ~0x0000000080000000;在32位系统上无法正常工作，尽管该代码可以正常处理其他两个值。 - supercat0x80000000被转换为unsigned long，没有进行任何其他操作。 - M.M0x80000000 已经是 unsigned int。它并没有被“转换为无符号”。当你调用函数时，unsigned int 会从 unsigned int 转换为 unsigned long，但这不会改变它的值。 - M.M因此，在具有32位或更少位int和32位或更大的unsigned int的系统上，0x80000000是一个无符号整数。
signed int型溢出的结果是未指定还是未定义的。我只知道它是“未定义的”，并且可能会陷入困境（实际上，在某些系统上会陷入困境）。此外，我的答案侧重于类型而不是值。经过进一步咨询，我相信它是未定义的。 - Mohit Jainftrapv)可启用陷阱机制。 - Mohit Jainint和unsigned int系统。
1适合于int，因此它是一个signed int，0x80000000不适合。对于十进制常量，将使用下一个更大的有符号类型来保存该值，而对于十六进制和八进制常量，则首先使用相应的无符号类型（如果适用）。这是因为它们通常是无符号的。有关完整的值/类型矩阵，请参见C标准，6.4.4.1p5。long 显然是64位的。int 将 1 移位到了符号位，正如您所预期的那样。int。int 会被转换为无符号的 unsigned，这样2的补码表示就不需要任何操作（只需要重新解释位模式）。unsigned long，因此符号被扩展到上位，成为 myprint 的参数。U 后缀，如这里的 1U 或者 0x1U）。int 更小的类型时，请注意标准整数转换。stdint.h 固定宽度类型。请注意，标准整数类型没有定义的位宽。对于 32 位，可以使用 uint32_t 来声明变量。对于常量，请使用宏： UINT32_C(1)（不带后缀！）。如果我错了，请纠正我。这就是我的理解。
在我的机器上，如M.M所说，sizeof(int) = 4。 （通过打印sizeof(int)确认）
因此，1 << 31变成（有符号的）0x80000000，因为1是有符号的。 但是，0x8000000变为无符号，因为它不能适合有符号int（因为它被视为正数，并且int的最大正数可以是0x7fffffff）。
因此，当有符号int转换为long时，会发生符号扩展（使用符号位进行扩展）。而当无符号int转换时，则使用0进行扩展。
这就是为什么在myprint（1 << 31）的情况下会有额外的1，而在以下情况下不是：
1）myprint（1u << 31）
2）myprint（1 << 31），当int> 32位时，因为在这种情况下，符号位不是1。
1 << 31 是未定义行为，您不能依赖或推断在此之后发生的任何事情。我不愿意在这里进一步猜测，因为人们会读到它并想到自己“它实际上不是未定义的，真正的故事是bla bla bla，我可以依靠它”。 - M.M
0x80000000。 - Jabberwockyint时会导致未定义行为。 - too honest for this sitemyprint函数中使用 1UL 而不是 1。myprintfunction(1UL << 31);默认情况下，没有限定符的值被表示为整数。 - campescassiano