Is integer behavior considered overflow yet undefined in C ++?

Question

As you know, signed integer overflow is undefined behavior . But there is something interesting in the C ++ 11 cstdint documentation:

with an integer type sign with a width of exactly 8, 16, 32 and 64 bits, respectively, without padding bits and using 2 additions for negative values (if only the implementation directly supports the type)

_{See link}

And here is my question: since the standard explicitly states that for int8_t , int16_t , int32_t and int64_t negative numbers are 2 additions, do these types still overflow with a undefined behavior?

Edit I checked the C ++ 11 and C11 standards, and here is what I found:

C ++ 11, §18.4.1:

The header defines all functions, types and macros in the same way as 7.20 in the C standard.

C11, §7.20.1.1:

The name typedef intN_t denotes an integer type with a sign with a width of N, no padding bits, and a double padding representation. Thus, int8_t denotes such a signed integer type with a width of exactly 8 bits.

Answer 1

still overflowing with these types of undefined behavior?

Yes. In paragraph 5/4 of the C ++ 11 standard (in relation to any expression in general):

If during the evaluation of the expression the result is not determined mathematically or if there are no representable values ​​for the type in the range, the behavior is undefined . [...]

The fact that a representation with two additions is used for these signed types does not mean that arithmetic modulo 2 ^ n is used to evaluate expressions of these types.

With respect to unsigned arithmetic, on the other hand, the standard explicitly states that (paragraph 3.9.1 / 4):

Unsigned integers declared unsigned , must obey the laws of arithmetic modulo 2 ^ n , where n is the number of bits in the representation of the values ​​of this particular integer size

This means that the result of an unsigned arithmetic operation is always "mathematically determined", and the result is always within the displayed range; therefore 5/4 is not applicable. Footnote 46 explains this:

46) This means that unsigned arithmetic is not overflowing, because a result that cannot be represented as a result of an unsigned integer type decreases modulo a number that is greater than the largest value that the resulting unsigned integer type can be represented.

Answer 2

Just because a type is defined to use a 2s representation view, it does not follow that the arithmetic overflow in this type becomes defined.

the undefined arithmetic overflow behavior of signatures is used to enable optimizations; for example, the compiler may assume that if a > b then a + 1 > b as well; this is not done in unsigned arithmetic, where the second check should be done because of the possibility that a + 1 might wrap around 0 . In addition, some platforms can generate a trap signal during arithmetic overflow (see, for example, http://www.gnu.org/software/libc/manual/html_node/Program-Error-Signals.html ); the standard continues to allow this to happen.

Answer 3

I would do so.

From the standard documentation (pages 4 and 5):

1.3.24 undefined behavior

for which this International Standard does not impose requirements

[Note: undefined behavior can be expected when this International Standard excludes any explicit definition of behavior or when a program uses erroneous construction or erroneous data. Acceptable undefined behavior varies from completely ignoring the situation to unpredictable results, behaving during a translation or program execution in a documented form that is characteristic of the environment (with or without a diagnostic message), to completing a translation or execution (with a diagnostic message). Many erroneous software constructs do not generate undefined behavior; they must be diagnosed .-- end of note]