Hacker News Reader

Comment by tstenner | Hacker News Reader

Was it the one with the elided null check?

I don't remember the details, roughly it was unexpected invocation of move semantic, causing use after free in a loop.

My all-time favourite example is (again, my memory, I may be a bit wrong):

    for (int i = 0; i < (size_t)limit; ++i) {
    }

at some point limit could potentially become greater than INT_MAX, the compiler decided that i<limit could never be true because that would cause signed int overflow which is UB, so it "optimized" the loop into

   while(true)

signed unsigned mismatch makes me shiver

The compiler cannot optimize that into `while(true)` because the original code does not encounter undefined behavior when `limit` is small enough to fit into `int`. What it can do: infer that `limit <= INT_MAX` and use that to optimize the code following after the loop (and in some cases, even the code before the loop).

This isn't complete example. I don't remember the details unfortunately.

But somehow compiler has decided that i <= limit is always true.

Reply on news.ycombinator.com