3 ms·

UB "making dead code live again" is not an example of UB in dead code making the execution undefined. Yes UB in live code can have surprising effects, includin

• smaudet 4y ago
  Unless your code is actually commented out (actually dropped from the program), it can still (maybe) execute. I think the main reason for this is an if(testSomeState()) { //code with UB } block being optimized to just //code with UB. Functions which are unreachable, maybe I agree, they can't be executed (without UB somewhere in reachable code). I'm not sure that's true though - if you have UB in your hardware (not your code), you can still execute that code. This is why (at least I was taught) never to leave dead code around. There's this better thing for that called source control you may have heard of... IF you have perfect hardware, and IF you have perfect logic/compiler and IF you have no UB in your program, then maybe you can guarantee that dead code is really dead, but I'm not really sure you want to heavily define dead code like that. Just remove it. Especially if it has UB in it to cause more fun bugs...
  • skitter 4y ago
    If UB happens¹, anything can happen. So if the check can only happen after UB, or leads to UB, it can be removed. That isn't the case in your example – testSomeState() can return false (and if it can't, it getting optimized out is unrelated do the code it guards). Points 14-16 from the article are just nonsense, UB is a runtime concept and dead code doesn't run unless you already triggered UB¹. ¹or is guaranteed to happen in the future