On Thu, Jun 30, 2005 at 03:14:54PM -0400, Paul Schlie wrote: > Given that the formal implication of GCC's choice not define signed integer > overflow semantics as being other than undefined will be to guaranteed that > all programs, with reachable signed integer arithmetic operations which can > not warrant that their respective operand expressions are recursively > constrained to each others corresponding additive, multiplicative inverse, > may produce unpredictably arbitrary results and/or behavior by default; > might it be a good idea to publish a formal rule/warning, as it's a good > thing to know and not particularly obvious:
The formal rule is called the ISO C standard. It's the only one you're going to get. > - Signed integer types and/or arithmetic operations should not be utilized > in GCC compiled programs (or any program desired to be strictly portable, > even if it's values are known or desired to be constrained to signed > integers) unless it is provably known that the corresponding operands to > all signed arithmetic operation which may use their values directly and/or > indirectly are correspondingly recursively constrained to their respective > additive or multiplicative inverse. As GCC complied programs may produce > arbitrary results and/or behavior in such instances by default, as enabled > by the C/C++ standards. Your alleged required condition is way too strict, to the point of being offensive, and you are falsely implying that GCC is aggressively doing what other compilers do not. The writer of a C program (or C++) needs to ensure that integer overflow does not occur when using signed types. If she fails to do this, we can't make any promise about the results, though in some cases the program might do what the user expects. Any promise we did make would inevitably harm the code quality for those who do write correct C programs, by preventing many common loops from being optimized. However, because we don't generate traps, in many cases programs that have overflows produce correct results anyway. It's just that we cannot promise that this will always be so. If the user does need the mathematical properties of arithmetic modulo 2**32 (8 or 16 or 64), he can readily obtain this by using unsigned types. The only correct way to write a bignum package in C, for example, is to use an unsigned type to store each word. Given your biases, you might be happier with Java as a language (than C or C++). The Java language designers decided to strictly define many cases that are not defined in C (example: the order side effects is always strictly left to right, floating point is always IEEE, etc., integer overflow wraps around). There is a performance penalty for this, but given the "write once, run everywhere" goal it was felt that it's worth paying this price.
