Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
381 views
in Technique[技术] by (71.8m points)

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

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 "
", INT32_MAX + 1);
    return 0;
}
See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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.)


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...