Re: Should GCC publish a general rule/warning due to it's defaultpresumption of undefined signed integer overflow semantics?

[Paul Schlie <schlie at comcast dot net>]

(sorry, meant additive/multiplicative inverse +/- MAX/MIN_<TYPE> value;
 but even that's wrong, which is why it seems that leaving signed overflow
 as being undefined is such a bad idea, as it becomes correspondingly very
 difficult to even try determine if a program is warranted to have a
 deterministic behavior, or potentially a completely arbitrary one.)

> 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 or 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:
> 
> - 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.
> 
> Or more generally as C/C++'s default integer promotion rules may convert
> unsigned integer types to signed operand types if it's other operand is
> signed, should the general rule be broadened to discourage the use of all
> integer variable types unless all signed integer operations which may utilize
> their values directly or indirectly are provably known to have
> their correspondingly operands constrained to their respective additive or
> multiplicative inverse value ranges?
> 
> (or if by default it warrants otherwise, maybe that should be stated?)