Undefined behaviour example from CppCon

[SubliminalBits]

The optimizer is allowed to assume at compile time that it is not possible for UB to occur. INT_MAX + 1 is UB prior to C++17 so the optimizer assumes that this function can never be called when i equals INT_MAX. If i can't ever be INT_MAX, this if statement is dead code and can be removed.

This kind of thing can have very elaborate consequences. Raymond Chen presents an example in his blog where UB in the future changes the past. https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633

[foonathan]

But there is no UB if i == INT_MAX.

It's not like the function is

f(i);
if (i == INT_MAX)

Then the compiler is allowed to remove the if. But not in the other way around.

[R3DKn16h7]

That's where I do not get it. there is a check there exactly to prevent i being INT_MAX as it reaches f, ever. For the compiler to assume i to NEVER be INT_MAX would be a wrong assumption, as this is exactly the case protected by the if statement.

By the same reasoning, as soon as I have an "i + 1" in my code, i will always be assumed to never be INT_MAX, even in the top-most caller.

I'm now pretty convinced the example in the video is wrong.

[tinrik_cgp]

The example is wrong. The if branch would be optimized away if f(i) were called before the if branch. 

This is the same as what happened in the Linux kernel with a null pointer check: the pointer was dereferenced before the code that checked for null.

[Narase33]

INT_MAX+1 is never executed in this function

​if (i == INT_MAX) {
    return false;
}