The C standard doesn't mandate tail-call optimization, but at least GCC and Clang are pretty good at doing it (-foptimize-sibling-calls, which is turned on with -O2)

That it is only an optimisation ensures it will eventually fail to trigger at the least convenient possible moment.

Unless your C implementation has TCE, don’t assume recursion is optimised.

> The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

Or you could, you know, use a normal loop...

Besides, since 2005 or thereabouts gcc with -O2 did proper tail-call optimisation so that the stack doesn't grow on a tail-call recursion.

Would that really happen though? I don't think I would actually release recursive code.

I find recursion to be very simple and elegant for prototyping algos, but I would instinctively rewrite it with an iterative/queue form as soon as the "toy" stage is over.

But why would you do that, if it's simple and elegant? Really the only answer is that it has potentially unbounded stack consumption - but tail recursion solves exactly that problem.

Not all recursive algorithms are tail recursive; not all tail recursive algorithms can be correctly identified & tail optimized.

Right, but OP was specifically talking about tail recursion.

goto would only help in cases of tail self-recursion, though.