32位无符号乘以64位导致未定义的行为?

Jub*_*ian 41 c undefined-behavior

所以我有这个代码:

uint32_t s1 = 0xFFFFFFFFU;
uint32_t s2 = 0xFFFFFFFFU;
uint32_t v;
...
v = s1 * s2; /* Only need the low 32 bits of the result */
Run Code Online (Sandbox Code Playgroud)

在以下所有内容中,我假设编译器不能对s1s2仅用于上述示例的初始化器的范围有任何先入之见.

如果我在一个整数大小为32位的编译器上编译它(例如编译x86时),没问题.编译器只是简单地使用s1s2作为uint32_t类型化的值(不能进一步推广它们),并且乘法将简单地给出结果,如注释所示(模数UINT_MAX + 1在这种情况下为0x100000000).

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

我对此是否正确,如果是这样,你会如何以理智的方式避免它?

我发现了这个类似的问题,但涵盖了C++:什么是最好的C++方式来模块化地安全地无符号整数?.在这里,我想得到一个适用于C的答案(最好是兼容C89).我不会考虑让一台糟糕的32位机器可能执行64位乘法,但这是一个可接受的答案(通常在代码中,这会引起关注,32位性能可能更为关键,因为通常那些机器速度较慢).

注意,当使用具有32位int大小的编译器编译时,同样的问题可以应用于16位无符号整数,或者当使用具有16位int大小的编译器编译时,同样的问题可以应用于无符号字符(后者可能与8位CPU的编译器相同) :C标准要求整数至少为16位,因此符合标准的编译器可能会受到影响).

小智 27

在无符号类型中实现乘法的最简单方法是至少uint32_t,也至少unsigned int是涉及类型的表达式unsigned int.

v = 1U * s1 * s2;
Run Code Online (Sandbox Code Playgroud)

这要么转换1Uuint32_t,或s1s2unsigned int,这取决于什么是适合你的特殊平台.

@Deduplicator评论说,一些uint32_t比较窄的编译器unsigned int可能会对赋值中的隐式转换发出警告,并注意到通过使转换显式化可能会抑制此类警告:

v = (uint32_t) (1U * s1 * S2);
Run Code Online (Sandbox Code Playgroud)

不过,在我看来,它看起来不那么优雅.

  • @ 2501那是对的.`1U*s1*s2`总是表示`(1U*s1)*s2`,`s1*s2*1U`总是表示`(s1*s2)*1U`.一个可能稍微更具可读性的替代方案,不要求读者知道`*`绑定如何,将是`s1*1U*s2`. (9认同)
  • @hvd这是有效的,因为乘法是从左到右,对吧?如果1U一直在右边,第一次乘法仍然是`s1*s2`并转换为int. (2认同)

Ded*_*tor 10

恭喜找到摩擦点.

一种可能的方式:

v = (uint32_t) (UINT_MAX<=0xffffffff
  ? s1 * s2
  : (unsigned)s1 * (unsigned)s2);
Run Code Online (Sandbox Code Playgroud)

无论如何,看起来像<stdint.h>为类型添加一些typedef 保证不会小于int顺序;-).