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. rcxdude · 1789746593 · focus · HN ↗

      The CPU doesn't really see functions, it just sees instructions. Functions are a convention on top of the machine code. What happens in this case is the compiler emits essentially a malformed function: it ends without performing a return, so execution just continues into the next function in memory. You can get the same behaviour by missing a 'return' statement from a function that needs one (though in that case I've also seen kind of the opposite: the function returns into the function two slots up in the stack, essentially returning from the function that called it! Undefined behaviour can utterly destroy normal control flow).

      Probably the process was one optimization pass saw that the function will never return due to an infinite loop, and removed the function return from the IR of the function, then a later pass saw that the infinite loop was a no-op and undefined so removed that as well, leaving a function that basically did nothing, not even return.

      1. echoangle · 1789749215 · focus · HN ↗

         > The CPU doesn't really see functions, it just sees instructions. Functions are a convention on top of the machine code.

         Not really true, most instructions set have instructions specifically to implement functions as found in normal programming languages. x86 has CALL and RET for example.

         <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;X86_calling_conventions" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;X86_calling_conventions

         Of course the compiler can stil optimize by inlining etc., but functions still mostly exist at the assembly level.

         1. rcxdude · 1789749859 · focus · HN ↗

            they have instructions for implementing them, but the important point here is that functions are still only defined by instructions that are executing between a call and ret instruction (or their equivalent more spelled-out equivalent operations), and not only can these not match up with what the compiler considers a function (for useful reasons like tail-calls as well as not-useful reasons like compiler bugs and UB), it might not be statically obvious exactly what instructions these are. So the CPU in practice has only a rough guess of where the function boundaries are (it might use these guesses for things like branch prediction, but they don&#x27;t define the visible execution of the code beyond the nuts and bolts of what those instructions actually do).

Unofficial Hacker News client; not affiliated with Y Combinator.