Answer.

Background

In C, arithmetic operations with integer types can lead to overflow when the result exceeds the representable range of the type, such as int or unsigned int. The specifics of the behavior on overflow are dictated by the language standards.

The Problem

Overflow with signed types (signed overflow) leads to undefined behavior, meaning the compiler has the right to perform any action: ignore the error, throw an exception, or produce an unpredictable result. For unsigned types, according to the C standard, the behavior on overflow is defined: it wraps around by the modulus of the type size (wraparound).

The Solution

For unsigned numbers, the overflow result is easily predictable, for example, UINT_MAX + 1 == 0. For signed numbers, it is recommended to check the type boundaries before operations using macros from <limits.h> or use static analysis tools. Modern compilers and tools can identify potential overflows.

Code Example:

#include <stdio.h>
#include <limits.h>

int add_with_check(int a, int b) {
    if (a > 0 && b > INT_MAX - a) {
        printf("Overflow will occur!
");
        return -1;
    }
    return a + b;
}

int main() {
    int x = INT_MAX, y = 1;
    printf("Result: %d
", add_with_check(x, y));
    unsigned int ux = UINT_MAX;
    printf("Unsigned overflow: %u
", ux + 1);
    return 0;
}

Key Features:

Unsigned overflow is defined and occurs by modulus
Signed overflow is undefined behavior; boundaries should always be checked
Use <limits.h> to obtain type sizes

Tricky Questions.

Is overflow of unsigned type an error?

No, this behavior is defined by the standard and is equivalent to a modulus reset. For example, (unsigned int)UINT_MAX + 1 == 0 is always true.

Can we rely on the fact that when int overflows, the result simply "wraps" around INT_MIN?

No, such behavior is not guaranteed and is not standardized; it is undefined behavior. It may crash, produce incorrect (platform-dependent) values, or be optimized by the compiler in an unpredictable way.

Can we depend on the behavior that int is always two's complement?

Although modern hardware almost always uses "two's complement" to represent signed int, the C language does not standardize this, so code with overflow will not be portable.

Common Mistakes and Anti-Patterns

Ignoring type boundary checks during arithmetic
Comparing/casting between signed and unsigned without explicit casts/checks
Assuming two's complement representation of int

Real-Life Example

Negative Case

Adding int numbers without boundary checking — overflow on large data leads to invalid calculations.

Pros:

Simple and fast code

Cons:

Hard-to-trace bugs on extreme data sets
Violates language standard

Positive Case

Before any arithmetic operations, a check for overflow is done using macros and functions. Using unsigned where wraparound is acceptable.