[gsg]

> As far as I understand it, this limitation is also the only thing preventing tail-call elimination in C/C++.

That is not the case. Guaranteed TCE requires deallocating the stack frame before jumping to the target, but that is not possible when an object is allocated in that frame and its address passed to the target function.

In C++ there is also the issue of destructors needing to run after the tail-call returns (in which case it is not really a tail-call).

C/C++ compilers can and do eliminate tail calls where possible, but there's no guarantee like you get from a compiler for a functional language.

[chriswarbo]

> that is not possible when an object is allocated in that frame and its address passed to the target function

Ah of course, I hadn't thought about live aliases to stack-allocated data.

You're right about destructors; I agree that they're not really tail-calls (since we're processing results).

> C/C++ compilers can and do eliminate tail calls where possible, but there's no guarantee like you get from a compiler for a functional language.

Yes, I tend to say "tail-call optimisation" when it's opportunistic (e.g. GCC/Clang), and "tail-call elimination" when it's guaranteed (e.g. Scheme/ML).