64位上的32位无符号乘法导致未定义的行为？

Question

所以我有这个代码：

uint32_t s1 = 0xFFFFFFFFU;
uint32_t s2 = 0xFFFFFFFFU;
uint32_t v;
...
v = s1 * s2; /* Only need the low 32 bits of the result */

在以下所有内容中，我假设编译器对s1 或s2 的范围没有任何先入之见，初始化程序仅用于上面的示例。

如果我在具有 32 位整数大小的编译器上编译它（例如在为 x86 编译时），没问题。编译器将简单地使用s1 和s2 作为uint32_t 类型值（无法进一步提升它们），并且乘法将简单地给出注释所述的结果（模UINT_MAX + 1，在这种情况下为0x100000000 )。

但是，如果我在具有 64 位整数大小的编译器上编译它（例如 x86-64），我可以从 C 标准推断出未定义的行为。整数提升将看到 uint32_t 可以提升为 int（64 位有符号），然后乘法将尝试将两个 int 相乘，如果它们恰好具有示例中显示的值，则会导致整数溢出，这是未定义的行为。

我对此是否正确，如果正确，您将如何以理智的方式避免它？

我发现了这个类似的问题，但涵盖了 C++：What's the best C++ way to multiply unsigned integers modularly safely?。在这里，我想得到一个适用于 C 的答案（最好与 C89 兼容）。我不会考虑让可能执行 64 位乘法的糟糕 32 位机器成为可接受的答案（通常在需要关注的代码中，32 位性能可能更关键，因为通常那些机器速度较慢）。

请注意，当使用 32 位 int 大小的编译器编译时，同样的问题可能适用于 16 位无符号整数，或者当使用具有 16 位 int 大小的编译器编译时，同样的问题可能适用于无符号字符（后者可能在编译器中很常见） 8 位 CPU：C 标准要求整数至少为 16 位，因此符合标准的编译器可能会受到影响。

Answer 1

在至少为uint32_t 且至少为unsigned int 的无符号类型中进行乘法运算的最简单方法是使用unsigned int 类型的表达式。

v = 1U * s1 * s2;

这会将1U 转换为uint32_t，或将s1 和s2 转换为unsigned int，具体取决于适合您的特定平台的内容。

@Deduplicator 发现某些编译器（其中uint32_t 比unsigned int 更窄）可能会警告赋值中的隐式转换，并指出通过显式转换可能会抑制此类警告：

v = (uint32_t) (1U * s1 * S2);

不过，在我看来，它看起来不太优雅。

Answer 2

恭喜你找到摩擦点。

一种可能的方式：

v = (uint32_t) (UINT_MAX<=0xffffffff
  ? s1 * s2
  : (unsigned)s1 * (unsigned)s2);

无论如何，看起来像为保证不小于int 的类型添加一些类型定义到<stdint.h> 将是有序的;-)。