------- Comment #53 from js at linuxtv dot org 2007-03-08 01:03 ------- I read all this and the mailing list thread with great interest, however I think there is a fundamental flaw in the reasoning:
C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow as "implementation-defined behaviour", which is something completely different than "undefined behaviour". See C90 3.11 vs. 3.18 / C99 3.4.1 vs. 3.4.3. (3.4.1 implementation-defined behavior: "unspecified behavior where each implementation documents how the choice is made"). And lo and behold: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Integers-implementation.html http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Integers-implementation.html "For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised." (Older versions of gcc left this undocumented.) Of course, software which relies on that is non-portable, but that's different from being "invalid C". If it turns out that many major C compilers use a similar implementation (which is what I expect but have no proof of), then it would be wise if gcc would do the same. E.g. Sun C uses this definitions: http://docs.sun.com/source/819-3688/c90.implementation.app.html#pgfId-998756 "When an integer is converted to a shorter signed integer, the low order bits are copied from the longer integer to the shorter signed integer. The result may be negative." Anyway, gcc should behave as documented, which isn't the case at least for gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475