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_MAX1在这种情况下是0x100000000）。

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

我说的对吗？如果是的话，你会如何理智地避免它？

我发现了一个类似的问题，但涵盖了C：安全模乘无符号整数的最佳C方法是什么？。在这里，我想得到一个适用于C的答案（最好是C89兼容）。我不会考虑制造一个可怜的32位机器，它可能会执行一个64位乘法一个可接受的答案（通常在代码中，这将是值得关注的，32位的性能可能会更为关键，因为通常是那些较慢的机器）。

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

Answer 1

恭喜你找到了摩擦点。

一种可能的方式：

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

总之，看起来像是在

Answer 2

要使乘法在至少为uint32_t且至少为unsigned int的无符号类型中发生，最简单的方法是使用类型为unsigned int的表达式。

v = 1U * s1 * s2;

这可以将1U转换为uint32_t，或者将s1和s2转换为无符号int，具体取决于适合您的特定平台的内容。

@重复数据消除程序指出，某些编译器（其中uint32_t的范围小于unsigned int）可能会对赋值中的隐式转换发出警告，并指出，通过显式转换，此类警告可能会被抑制：

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

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