C 中模数运算符的无符号溢出
我在编写的一些 C 代码中遇到了一个错误，虽然它相对容易修复，但我希望能够更好地理解其背后的问题。本质上发生的事情是我有两个无符号整数（实际上是uint32_t），当应用模数运算时，产生了一个负数的无符号等价物，一个被包装的数字，因此是“大”的。这里有一个示例程序来演示：
#include <stdio.h>
#include <stdint.h>
int main(int argc, char* argv[]) {
uint32_t foo = -1;
uint32_t u = 2048;
uint64_t ul = 2048;
fprintf(stderr, "%d\n", foo);
fprintf(stderr, "%u\n", foo);
fprintf(stderr, "%lu\n", ((foo * 2600000000) % u));
fprintf(stderr, "%ld\n", ((foo * 2600000000) % u));
fprintf(stderr, "%lu\n", ((foo * 2600000000) % ul));
fprintf(stderr, "%lu\n", foo % ul);
return 0;
}
在我的 x86_64 机器上，这会产生以下输出：
-1
4294967295
18446744073709551104
-512
1536
2047
1536 是我期望的数字，但 (uint32_t)(-512) 是我得到的数字，正如你想象的那样，它抛出了事情有点不对劲。
所以，我想我的问题是：为什么在这种情况下两个无符号数之间的模运算会产生一个大于除数的数字（即负数）？这种行为受到青睐有什么原因吗？
i encountered a bug in some c code i wrote, and while it was relatively easy to fix, i want to be able to understand the issue underlying it better. essentially what happened is i had two unsigned integers (uint32_t, in fact) that, when the modulus operation was applied, yielded the unsigned equivalent of a negative number, a number that had been wrapped and was thus "big". here is an example program to demonstrate:
#include <stdio.h>
#include <stdint.h>
int main(int argc, char* argv[]) {
uint32_t foo = -1;
uint32_t u = 2048;
uint64_t ul = 2048;
fprintf(stderr, "%d\n", foo);
fprintf(stderr, "%u\n", foo);
fprintf(stderr, "%lu\n", ((foo * 2600000000) % u));
fprintf(stderr, "%ld\n", ((foo * 2600000000) % u));
fprintf(stderr, "%lu\n", ((foo * 2600000000) % ul));
fprintf(stderr, "%lu\n", foo % ul);
return 0;
}
this produces the following output, on my x86_64 machine:
-1
4294967295
18446744073709551104
-512
1536
2047
1536 is the number i was expecting, but (uint32_t)(-512) is the number i was getting, which, as you might imagine, threw things off a bit.
so, i guess my question is this: why does a modulus operation between two unsigned numbers, in this case, produce a number that is greater than the divisor (i.e. a negative number)? is there a reason this behavior is preferred?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为原因是编译器将
2600000000文字解释为带符号的 64 位数字，因为它不适合带符号的 32 位 int。如果将数字替换为2600000000U，您应该会得到预期的结果。I think the reason is that the compiler is interpreting the
2600000000literal as a signed 64-bit number, since it does not fit into a signed 32-bit int. If you replace the number with2600000000U, you should get the result you expect.我没有方便的参考，但我很确定当您进行乘法时，它会将它们提升为 int64_t ，因为它需要将两个被乘数强制为有符号整数类型。尝试
2600000000u而不是2600000000....I don't have a reference handy, but I'm pretty sure when you do that multiplication, it promotes them to
int64_t, because it needs to coerce the two multiplicands to a signed integral type. Try2600000000uinstead of2600000000....