‹ BackHN Continuity

Thread

C++26: Trivial infinite loops are no longer undefined behaviour

173 points · 290 comments · ibobev

  1. adzm · · focus · HN ↗
    i have never before thought that a function could 'fall through' to another function. why does this behavior even exist?
    1. kzrdude · · focus · HN ↗
      Well you leave the C++ realm (execution model), as you should with UB and it depends on implementation. The implementation of the compiler was such that the two functions are placed after each other in the machine code; and if the first function doesn't return, then you continue executing into the code for the next function.
      1. Someone · · focus · HN ↗
        But the compiler assumes the function will make forward progress. If the function does that, it will return, so why doesn’t the compiler emit a function epilogue?
        1. muvlon · · focus · HN ↗
          The compiler can assume that the function will return, but it can also statically deduce that the function cannot return. That's a contradiction, so the compiler deduces that the function is simply UB when called, i.e. no need to emit an epilogue. It's the logical principle of explosion in compiler format, basically.
        2. gizmo686 · · focus · HN ↗
          Because there is an infinite loop that makes the epilogue unreachable, so it is safe for the compiler to remove it!

          Sure, that optimization interacts badly with the optimization that removes the infinite loop. But half the point of UB is to avoid needing to deal with such interactions, because they are defined out of existence.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.