| ▲ | qazxcvbnmlp 4 days ago |
| 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++. |
|
| ▲ | aka-rider 4 days ago | parent | next [-] |
| 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. |
| |
| ▲ | tstenner 4 days ago | parent [-] | | Was it the one with the elided null check? | | |
| ▲ | aka-rider 3 days ago | parent [-] | | 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 | | |
| ▲ | dgrunwald 3 days ago | parent [-] | | 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). | | |
| ▲ | aka-rider 3 days ago | parent [-] | | This isn't complete example. I don't remember the details unfortunately. But somehow compiler has decided that i <= limit is always true. |
|
|
|
|
|
| ▲ | itemize123 3 days ago | parent | prev [-] |
| interesting, c -> c++ transition should be smooth though |