Do C99 signed integer types defined in stdint.h exhibit well-defined behaviour in case of an overflow?

Question

All operations on "standard" signed integer types in C (short, int, long, etc) exhibit undefined behaviour if they yield a result outside of the [TYPE_MIN, TYPE_MAX] interval (where TYPE_MIN, TYPE_MAX are the minimum and the maximum integer value respectively. that can be stored by the specific integer type.

According to the C99 standard, however, all intN_t types are required to have a two's complement representation:

7.8.11.1 Exact-width integer types
1. The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits.

Does this mean that intN_t types in C99 exhibit well-defined behaviour in case of an integer overflow? For example, is this code well-defined?

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

int main(void)
{
    printf("Minimum 32-bit representable number: %" PRId32 "\n", INT32_MAX + 1);
    return 0;
}

Answer 1

No, it doesn't.

The requirement for a 2's-complement representation for values within the range of the type does not imply anything about the behavior on overflow.

The types in <stdint.h> are simply typedefs (aliases) for existing types. Adding a typedef doesn't change a type's behavior.

Section 6.5 paragraph 5 of the C standard (both C99 and C11) still applies:

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

This doesn't affect unsigned types because unsigned operations do not overflow; they're defined to yield the wrapped result, reduced modulo TYPE_MAX + 1. Except that unsigned types narrower than int are promoted to (signed) int, and can therefore run into the same problems. For example, this:

unsigned short x = USHRT_MAX;
unsigned short y = USHRT_MAX;
unsigned short z = x * y;

causes undefined behavior if short is narrower than int. (If short and int are 16 and 32 bits, respectively, then 65535 * 65535 yields 4294836225, which exceeds INT_MAX.)

Answer 2

Although storing an out-of-range value to a signed type stored in memory will generally store the bottom bits of the value, and reloading the value from memory will sign-extend it, many compilers' optimizations may assume that signed arithmetic won't overflow, and the effects of overflow may be unpredictable in many real scenarios. As a simple example, on a 16-bit DSP which uses its one 32-bit accumulator for return values (e.g. TMS3205X), int16_t foo(int16_t bar) { return bar+1;} a compiler would be free to load bar, sign-extended, into the accumulator, add one to it, and return. If the calling code were e.g. long z = foo(32767), the code might very well set z to 32768 rather than -32768.