请教C语言牛人----关于int与unsigned int的奇怪问题

starwing83

其实有个附录的…………

关于Integer，我只找到conversions里面有一个，如果float转换到int超过了int的range，就是undefined behavior，剩下的的确是不知道……

starwing83

有没有直接的条款说明int之间的加法造成的overflow是undefined behavior的？

additive operators（6.5.6）里面没有说明；
signed and unsigned integers（6.3.1.3）里面没有说明；

除了一个不知道哪儿还没有收入附录J的EXAMPLE以外实在是没找到哪儿还说明了overllow问题，搜索了整个pdf还是没找到。

在搜索中，发现char c1 = c2 + c3;如果overflow不算未定义行为，因为有integer promtion。

求高人指点。

群雄逐鹿中原

6.2.5指出unsigned永远不会overflow.
更关键的是注意他的这个because说辞。
用同样的原因，也可以说signed本身永远不会overlfow. （虽然文档没说，但我们如果承认这个because有效，就必须推出这样的结论）

The range of nonnegative values of a signed integer type is a subrange of the
corresponding unsigned integer type, and the representation of the same value in each
type is the same.
31)
Acomputation involving unsigned operands can neveroverflow,
because a result that cannot be represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the largest value that can be
represented by the resulting type

starwing83

但是没有直接说int吧？unsigned是可以用取模，但是signed不行吧？》

群雄逐鹿中原

理想与现实的差距：
标准说实现可以定义成signed也取模不需检查overflow.
虽然说是 “可以”，但似乎已成事实标准，有人敢弄例外，造这个天下之大不韪么？

H.2.2 Integertypes
1The signed C integer types int, long int, long long int,and the corresponding
unsigned types are compatible with LIA−1.If an implementation adds support for the
LIA−1 exceptional values ‘‘integer_overflow’’and ‘‘undefined’’, then those types are
LIA−1 conformant types.C’sunsigned integer types are ‘‘modulo’’inthe LIA−1 sense
in that overflows or out-of-bounds results silently wrap.An implementation that defines
signed integer types as also being modulo need not detect integer overflow, inwhich case,
only integer divide-by-zero need be detected.

OwnWaterloo

哈， 越来越有意思了  我也来参合参合


这段话有2处读不懂……

are compatible with LIA−1
are LIA−1 conformant types

什么叫compatible with LIA-1？
什么叫are LIA−1 conformant types？
分别是什么意思？

An implementation that defines signed integer types as also being modulo need not detect integer overflow, inwhich case, only integer divide-by-zero need be detected.

这句话更迷惑了…… 完全读不懂…… 连句子的主干都没看明白……


-------------------------------

个人理解，  附录H描述的已经不是C语言了， 而是另一个标准：
“ISO/IEC 10967−1” , Language independent arithmetic, LIA−1

H.1 Introduction
This annex documents the extent to which the C language supports the ISO/IEC 10967−1
standard for language-independent arithmetic (LIA−1).
LIA−1 is more general than IEC 60559 (annex F) in that it covers integer and diverse floating-point arithmetics.

IEC 60559就是IEEE754啦。

也就是说， 无论LIA-1和IEEE754的描述如何， 它们都不是C标准。
比如有一个用IEEE754求最高1bit的index的trick， 只能在ieee754下才有效。
在C中不一定有效，  印象中x86老一些的机器就不遵循ieee754。
也许新设计的机器应该都会遵守ieee754？ 新出现的机器应该不会有各种古怪的东西？
那要提供对老机器的兼容性么？

而且， 古怪也是相对的。
现在可能觉得flat寻址才是正常， segment + offset是古怪。
有可能在10-20年前， 程序员会觉得segment + offset才是王道， 很自然， 就应该这样。
也有可能10-20年后， flat寻址会被视为古怪， legacy。

---------------------------------------

在C99正文中有一段有意思的话：

5.1.2.3(Program execution) - 14

EXAMPLE 6 To illustrate the grouping behavior of expressions, in the following fragment

int a, b;
/* ... */
a = a + 32760 + b + 5;

the expression statement behaves exactly the same as

a = (((a + 32760) + b) + 5);

due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is next added to b, and that result is then added to 5 which results in the value assigned to a.

On a machine in which overflows produce an explicit trap and in which the range of values representable by an int is [−32768, +32767], the implementation cannot rewrite this expression as

a = ((a + b) + 32765);

since if the values for a and b were, respectively, −32754 and −15, the sum a + b would produce a trap while the original expression would not; nor can the expression be rewritten either as

a = ((a + 32765) + b);

or

a = (a + (b + 32765));

since the values for a and b might have been, respectively, 4 and −8 or −17 and 12.

However, on a machine in which overflow silently generates some value and where positive and negative overflows cancel, the above expression statement can be rewritten by the implementation in any of the above ways because the same result will occur.

这段至少说明： C标准有考虑过溢出会产生trap的机器。
为什么要考虑这种机器呢？ 是否因为这种机器确实存在？
而且……  在这种机器上……  C语言应该如何实现呢？
是检测出这种情况， 并默默的修复？ —— 这不符合C的习惯吧？
还是让程序员去处理？ —— 这要怎么编程啊……  连个加法都不安全了……

困惑……