Live data from Hacker News

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

lwn.net

21–30 of 128 posts

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

#21
post #15

I think Anton is replying to me in that LWN article IIRC. I personally didn't know C only had tail calls that late and learnt something new there! On the other hand, I am pretty new to the compiler space myself, and I count early 2000s as a pretty long time ago, though again it is not that far back considering how long other language implementations had tail calls like in ML or variants since 1980-90s.

It still doesn't, this is a compiler specific language extension. You won't find anything on ISO/IEC 9899:2024 about tail calls, like it happens on Scheme. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf Section 3.5 of R7RS. https://standards.scheme.org/official/r7rs.pdf

A formal technical specification (TS) extension is already being drafted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3582.pdf That's a step up from the usual proposals. I'm not sure what criteria is used to decide whether to first create a TS vs just incorporating a change into the working draft of the next standard.[1] _Defer also seems to be taking the TS route.[2]

1. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf

2. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3928.pdf

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

#22

> In 2001 Mark Probst implemented tail-call optimization in GCC MSVC didn't add tail-call optimisation until sometime in the 2010s, IIRC. I distinctly remember sending a tail-recursive C++ program to someone who developed on Windows, and it crashing, in the late mid-to-late 2000s.

MSVC stands for MicroSoft Visual C++ compiler AFAIK.

It famously doesn’t support a few features of C99.

They don’t really seem to care much about regular C support (non-C++).

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

#23
post #21
post #15

Earlier quoted context omitted.

It still doesn't, this is a compiler specific language extension. You won't find anything on ISO/IEC 9899:2024 about tail calls, like it happens on Scheme. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf Section 3.5 of R7RS. https://standards.scheme.org/official/r7rs.pdf

A formal technical specification (TS) extension is already being drafted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3582.pdf That's a step up from the usual proposals. I'm not sure what criteria is used to decide whether to first create a TS vs just incorporating a change into the working draft of the next standard.[1] _Defer also seems to be taking the TS route.[2] 1. https://www.open-std.org/jtc1/sc22/wg14/…

Well, even if that lands on the official standard, that means C29 as probable release year for C2y, plus adoption of the exact form across compilers to be able to rely on it being available.

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

#24
post #5

> In 2001 Mark Probst implemented tail-call optimization in GCC with a separate calling convention; he lists the limitations of the then-existing tail-call optimization in GCC in section 6.4, among them: "It cannot handle indirect calls" (which would have been used in tail calls for interpreter dispatch). Relatively recent being a quarter of century? Or at least a fifth of a century for indirect calls[1] (GCC 3.4.6 i…

Given that GCC was first released in 1987, that would mean that tail call optimization, including of indirect calls, has been around for more than half of GCC's lifetime. So it's indeed fair for the parent article to say that "[GCC has] had tail-call optimizations for most of [its] existence".

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

#25
post #5

> In 2001 Mark Probst implemented tail-call optimization in GCC with a separate calling convention; he lists the limitations of the then-existing tail-call optimization in GCC in section 6.4, among them: "It cannot handle indirect calls" (which would have been used in tail calls for interpreter dispatch). Relatively recent being a quarter of century? Or at least a fifth of a century for indirect calls[1] (GCC 3.4.6 i…

For people who passed their 30s, everything that happened after their 20th birthday is recent. For me, September 11 is recent memory, as well as the 2008 great recession.

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

#27

> In 2001 Mark Probst implemented tail-call optimization in GCC MSVC didn't add tail-call optimisation until sometime in the 2010s, IIRC. I distinctly remember sending a tail-recursive C++ program to someone who developed on Windows, and it crashing, in the late mid-to-late 2000s.

MSVC stands for MicroSoft Visual C++ compiler AFAIK. It famously doesn’t support a few features of C99. They don’t really seem to care much about regular C support (non-C++).

They officially saw no need for C support going forward.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

Note,

"If you really need either of the following.....then we recommend that you consider using a different compiler such as Intel or gcc (short-term) and/or pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term)."

Which is kind of why nowadays clang is part of Visual Studio as well.

However, after Satya got into the whole Microsoft https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

There are a few blogs after that, so at least up to C17 minus the optional parts from C11, the support is there.

It remains to be seen if anything C23 or later will ever come into MSVC, and then again, clang is part of VS installer.

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

#28
post #6

>That quote is the article, and it's a little surprising that it's buried so far into the content Is it really surprising in 2026? Today's online writing style is not primarily designed to communicate. It's designed to keep the reader 'engaged' for as long as possible. The reader's time is a resource to be extracted. I'm absolutely not poking this author individually. It's the writing style of the net.

I was wondering what this was in reference to; it's not in reference to TFA here. It's a quote from https://bytecode.news/posts/2026/08/because-it-s-not-fun-eno..., so presumably you meant to post this over at https://news.ycombinator.com/item?id=49242245.

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

#29
post #21
post #15

Earlier quoted context omitted.

It still doesn't, this is a compiler specific language extension. You won't find anything on ISO/IEC 9899:2024 about tail calls, like it happens on Scheme. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf Section 3.5 of R7RS. https://standards.scheme.org/official/r7rs.pdf

A formal technical specification (TS) extension is already being drafted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3582.pdf That's a step up from the usual proposals. I'm not sure what criteria is used to decide whether to first create a TS vs just incorporating a change into the working draft of the next standard.[1] _Defer also seems to be taking the TS route.[2] 1. https://www.open-std.org/jtc1/sc22/wg14/…

There's some discussion of how C29 defer ended up in a TS at https://thephd.dev/c2y-the-defer-technical-specification-its... .

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

#30
post #23
post #21

Earlier quoted context omitted.

A formal technical specification (TS) extension is already being drafted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3582.pdf That's a step up from the usual proposals. I'm not sure what criteria is used to decide whether to first create a TS vs just incorporating a change into the working draft of the next standard.[1] _Defer also seems to be taking the TS route.[2] 1. https://www.open-std.org/jtc1/sc22/wg14/…

Well, even if that lands on the official standard, that means C29 as probable release year for C2y, plus adoption of the exact form across compilers to be able to rely on it being available.

Plus the fact that an implementation that recognizes the new syntax and produces an error whenever it encounters it will be conforming.

On such an implementation, the feature is available but useless.

Post reply on HN