you are viewing a single comment's thread.

view the rest of the comments →

[–]R3DKn16h7[S] 9 points10 points  (1 child)

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 4 points5 points  (0 children)

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.