> Paolo Bonsini wrote:
>> Upon a potential integer overflow of either it's min or max range,
>> shouldn't the result be set to [min:type-min-value, max:type-max-value],
>> without the necessity of any further designations?
>
> No.
>
> [10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed
> int overflow definition in the C standard.
>
> [10U, UINT_MAX] + [ 1U, 1U ] == ~[ 1U, 10U ]
??? Do you mean:
H.2.2 Integer types
[#1] The signed C integer types int, long, long long 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's unsigned integer types are "modulo" in the
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, in which case,
only integer divide-by-zero need be detected.
Where in combination with:
5.1.2.3 Program execution
Examples 2. In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the ``integer promotions'' require that the abstract
machine promote the value of each variable to int size
and then add the two ints and truncate the sum.
Provided the addition of two chars can be done without
overflow, or with overflow wrapping silently to
produce the correct result, the actual execution need
only produce the same result, possibly omitting the
promotions.
It seems pretty clear given that for all practical purposes all typical
machines do silently wrap integer overflow, they all correspondingly yield:
[10, INT_MAX] + [ 1, 1 ] == [INT_MIN, INT_MAX ]
[10U, UINT_MAX] + [ 1U, 1U ] == [UINT_MIN, UINT_MAX]
or more generally: [<INTEGER-TYPE>_MIN, <INTEGER-TYPE>_MAX] upon overflow.
