Comment by fluoridation

Your problem is that you're treating words such as "function" and "call" as if they had meaning outside of the language itself (or, more specifically, outside of the C abstract machine), when the point of the compiler is precisely to melt away the language parts of the specified program and be left with a concrete program that matches its behavior. If you view a binary in a disassembler, you will not find any "functions" or "calls". Maybe that particular architecture happens to have a "call" instruction to jump to "functions", but these words are merely homophones with what C refers to as "functions" and "calls".

When you "call" a "function" in the source you're not specifying to the compiler that you want a specific opcode in the generated executable, you're merely specifying a particular observable behavior. This is why optimizations such as inlining and TCO are valid. If the compiler can prove that a heap allocation can be turned into a stack allocation, or even removed altogether (e.g. free(malloc(1ULL << 50))), the fact that these are exposed to the programmer as "functions" he can "call" poses no obstacle.