(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?)
