Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tail-call optimization in C is relatively recent (2025)

lwn.net

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Tail-call optimization in C is relatively recent (2025)

#131

Post by pjmlp »

uecker wrote: post #103
pjmlp wrote: post #86

Earlier quoted context omitted.

As proven by industry adoption of clang, that isn't an option in many platforms. Additionally clang is driving C extensions for safety that should have long been part of the language.

IMHO gcc has better warnings and support for safety. Industry mostly wants a BSD-licensed toolchain. I could not care less.

GCC only recently started with its safety analysers, it doesn't do C++, and isn't as customisable as clang tidy.

Additionally it lacks the language extensions Apple and Google have been adding to clang, which remains to be seen which ever get proposed to be part of the standard.

You might care less, however as mentioned there are industry relevant platforms where GCC doesn't get to play at all, thus plenty of people do care.

Re: Tail-call optimization in C is relatively recent (2025)

#132

Post by uecker »

pjmlp wrote: post #131
uecker wrote: post #103

Earlier quoted context omitted.

IMHO gcc has better warnings and support for safety. Industry mostly wants a BSD-licensed toolchain. I could not care less.

GCC only recently started with its safety analysers, it doesn't do C++, and isn't as customisable as clang tidy. Additionally it lacks the language extensions Apple and Google have been adding to clang, which remains to be seen which ever get proposed to be part of the standard. You might care less, however as mentioned there are industry relevant platforms where GCC doesn't get to play at all, thus plenty of people…

This discussion was about C not C++. GCC also has language extensions for safety, such as the access attribute, the dynamic object size pass, and far better warnings.

Big tech cares about a lot of things of dubious value to me, the users, or developers. As a C programmer, if you want to write modern and safe C, my recommendation is to use gcc.

Re: Tail-call optimization in C is relatively recent (2025)

#133

Post by uecker »

fluoridation wrote: post #85
uecker wrote: post #84

Earlier quoted context omitted.

It is usually assumed that it does not control the callee and the jump has to preserve the calling convention for a call.

If it doesn't control both then TCO is impossible, because the stack will grow with each recursive step, as it's just performing a normal call.

Have your mind blown: https://godbolt.org/z/xnn3PPxvW

Re: Tail-call optimization in C is relatively recent (2025)

#134

Post by Someone »

vanderZwan wrote: post #105
Someone wrote: post #89

Earlier quoted context omitted.

> I can only think of a few other optimizations that affect memory usage Java has string interning. I think that’s a hack that shouldn’t exist in an ideal world. Reason is that, as a library writer, you cannot make the call whether to intern strings (requiring more instructions for string access, thus slowing down code, but decreasing memory usage, and, because of that, possibly speeding up the code again) or not.

> requiring more instructions for string access Wait, why would interned immutable strings require more instructions when doing regular string access? You can still point to the start of a zero-terminated C-string, it just requires storing extra metadata like lenght and a string hash somewhere. Which can be done at the negative indices of said pointer. Or do you refer to the extra rolling-hash pass needed when concat…

> Wait, why would interned immutable strings require more instructions when doing regular string access

Sorry, I wasn’t precise. Accessing them won’t take more instructions, but setting them up does.

> Or do you refer to the extra rolling-hash pass needed when concatenating two strings to verify if it would result in an already-interned one?

I don’t think the JVM does that.

Re: Tail-call optimization in C is relatively recent (2025)

#135

Post by fluoridation »

uecker wrote: post #133
fluoridation wrote: post #85

Earlier quoted context omitted.

If it doesn't control both then TCO is impossible, because the stack will grow with each recursive step, as it's just performing a normal call.

Have your mind blown: https://godbolt.org/z/xnn3PPxvW

Extremely specific example is uncompelling.

Re: Tail-call optimization in C is relatively recent (2025)

#136

Post by teo_zero »

fluoridation wrote: post #115
teo_zero wrote: post #114

Earlier quoted context omitted.

The example you set up was about f() calling into g() calling into h(). Why do you mention h() calling into g() now? The whole thread is about how the traditional calling convention makes it difficult to implement TCO in C. Functions with different arity having different stack layout is indeed one of the roadblocks, so I think we agree here, no?

That was in response to a specific point that TCO needed callee-cleanup. But nobody cares about TCO in non-recursive call stacks, and nobody does cross-module recursion. Hence my question: if the only situation where anyone would care whether TCO is being performed is one in which the compiler can see both sides of the call, what does it matter what the calling convention is? The compiler is not bound to use any call…

Ah, now I see that indeed we agree without understanding each other. The source is a misinterpretation of your sentence far up the thread:

> I can't see why the calling convention could matter.

The "could matter" was understood as "would influence TCO" and so the rest of the thread was devoted to explain how the two are connected, while you meant "should be fixed and not be changed at the compiler's whims".

And you are right, of course: if a function is static and its address is never taken, the compiler can choose whatever calling strategy it wants, possibly one that facilitates TCO.

Post reply on HN