Putting multiple Erlang functions into a single C function to avoid using C’s stack sounds awesome but also horrifying.
Why's that horrifying? Isn't inlining a super-basic and well-understood optimisation that any serious compiler would be doing?
> BEAM/C generated a single C function for each Erlang module. Local calls within the module were made by explicitly pushing the return address to the Erlang stack followed by a goto to the label of the called function. (Strictly speaking, the calling function stores the return address to BEAM register and the called function pushes that register to the stack.)
> Calls to other modules were done similarly by using the GCC extension that makes it possible to take the address of a label and later jumping to it. Thus an external call was made by pushing the return address to the stack followed by a goto to the address of a label in another C function.
> Isn’t that undefined behavior?
> Yes, it is undefined behavior even in GCC.
From the C standard:
> The identifier in a goto statement shall name a label located somewhere in the enclosing function.
`Shall` is a term of art here:
> If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behavior is undefined.
(Sections 6.8.6.1.1 and 4.2, respectively: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
> it is undefined behavior even in GCC. It happened to work with GCC on Sparc, but not on GCC for X86.