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. kzrdude · 1789744785 · 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 · 1789746876 · 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 · 1789750944 · 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 · 1789751114 · 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.

      2. raverbashing · 1789747108 · focus · HN ↗

         This makes no sense to me

         If I think about asm:

         function1:

             (do stuff)
         
             jp function1
         
             ret
         
         

         function2:

             (other stuff)
         
             ret
         
         

         main:

             call function1
         
             call function2
         
         

         the 2nd call might happen internally due to branch prediction but in practice it shouldn't and the processor fixes this

         Oh yeah and TFA also goes with:

         > The funny bit is that C got this right.(...) but C included one more rule: loops whose controlling expression is a constant expression may not be assumed to terminate.

         Well, duh! A broken clock is right twice a day it seems

         1. rcxdude · 1789747235 · focus · HN ↗

            With UB the compiler has no particular requirement to emit the 'ret'. (or, in the example, anything at all for the function)
         2. [deleted] · 1789758930 · focus · HN ↗

            [deleted]

Unofficial Hacker News client; not affiliated with Y Combinator.