behavior when for-loop variable overflow and compiler optimization

… then i will be assigned INT_MAX+1, which would overflow to an undefined value such as between 0 and INT_MAX.

No, that is not correct. That is written as if the rule were:

• If ++i overflows, then i will be given some int value, although it is not specified which one.

However, the rule is:

• If ++i overflows, the entire behavior of the program is undefined by the C standard.

That is, if ++i overflows, the C standard allows any of these things to happen:

• i stays at INT_MAX.
• i changes to INT_MIN.
• i changes to zero.
• i changes to 37.
• The processor generates a trap, and the operating system terminates your process.
• Some other variable changes value.
• Program control jumps out of the loop, as if it had ended normally.
• Anything.

Now consider this assumption used in optimization by the compiler:

… the compiler can assume that the loop will iterate exactly N+1 times…

If ++i can only set i to some int value, then the loop will not terminate, as you conclude. On the other hand, if the compiler generates code that assumes the loop will iterate exactly N+1 times, then something else will happen in the case when ++i overflows. Exactly what happens depends on the contents of the loop and what the compiler does with them. But it does not matter what: Generating this code is allowed by the C standard because whatever happens when ++i overflows is allowed by the C standard.

Lets consider an actual case:

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

unsigned long long test_int(unsigned long long L, int N) {
    for (int i = 0; i <= N; ++i) {
        L++;
    return L;
}

unsigned long long test_unsigned(unsigned long long L, unsigned N) {
    for (unsigned i = 0; i <= N; ++i) {
        L++;
    return L;
}

int main() {
    fprintf(stderr, "int: %llu\n", test_int(0, INT_MAX));
    fprintf(stderr, "unsigned: %llu\n", test_unsigned(0, UINT_MAX));
    return 0;
}

The point of the blog article is the of possible behavior of the compiler for the above code:

• for test_int() the compiler can determine that for argument values from INT_MIN to -1, the function should return L unchanged, for values between 0 and INT_MAX-1, the return value should be L + N + 1 and for INT_MAX the behavior is undefined, so returning L + N + 1 is OK too, hence the code can be simplified as

    unsigned long long test_int(unsigned long long L, int N) {
        if (N >= 0)
            L += N + 1;
        return L;
    }
  

• for test_unsigned(), the same analysis yields: for argument values below UINT_MAX, the return value is L + N + 1 and for UINT_MAX there is an infinite loop:

    unsigned long long test_unsigned(unsigned long long L, unsigned N) {
        if (N != UINT_MAX)
            return L + N + 1;
        for (;;);
    }
  

As can be seen on https://godbolt.org/z/abafdE8P4 both gcc and clang perform this optimisation for test_int, taking advantage of undefined behavior on overflow but generate iterative code for test_unsigned.

Signed integer overflow invokes the Undefined Behaviour. Programmer cannot assume that a portable program will behave the particular way.

On the other hand, a program compiled for the particular platform using particular version of the compiler and using the same versions of the libraries will behave deterministic way. But you do not know if any of those change (ie. compiler, compiler version etc etc) that the behaviour will remain the same.

So your assumptions can be valid for the particular build and execution environment, but are invalid in general.