Hacker News Reader

Comment by qazxcvbnmlp | Hacker News Reader

I work on a C++ codebase. I frequently prototype in c and then have the ai model slopify it back to c++. Nice b/c I am faster at reading c, but hard b/c you miss some of the features/nuances of c++.

View on HN

I would be afraid to do this with C++.

My friend once sent me a snippet, maybe 10 lines of C+++, asking "can you spot the UB?".

So I'm staring at these 10 lines, I KNOW there is an UB. I wasn't able to find it without a hint.

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.

interesting, c -> c++ transition should be smooth though

Reply on news.ycombinator.com