Thread

1. adzm · 1789744548 · focus · HN ↗

   i have never before thought that a function could 'fall through' to another function. why does this behavior even exist?

   1. apple1417 · 1789746959 · focus · HN ↗

      The assembly gives a bit of a hint as to what's happening.

          main:
          
          unreachable():
                  push    rbx
                  ...
      

      Due to the undefined behavior, it decides calling main must be impossible, so the easiest thing to do is just give up, don't bother defining the rest of it. You can also do the same with std::unreachable(). But the label for the function still sticks around for some reason, so when you jump to it, it falls through. Which leads to the really stupid fact that reordering the functions changes the behavior.

      I assume there are good reasons they can't just completely delete the label. Maybe it would screw linking, or with cases where you deliberately have multiple labels for the same function. And if the effect is only visible due to undefined behavior, it's not technically wrong. But I have always thought this is such a stupid case, surely it can't be that complex to add a trap instruction, even in an optimized build you shouldn't really care if it slows down a function that's "never called".

      1. rcxdude · 1789747433 · focus · HN ↗

         I suspect it's more a chain of: emitting the ret is unnecessary because the infinite loop will never return -> emitting the infinite loop is unnecessary because there's no side effects within it and it's undefined behaviour -> emitting any setup for the function is necessary because it's doing nothing else (all probably decisions from different stages of the compiler).

Unofficial Hacker News client; not affiliated with Y Combinator.