It's been officially supported in GCC since about a decade ago, I believe. It's not part of the C language, so if you're writing this code, it's no longer C. It also requires executable stacks.
The article indicates its not officially supported, although it could be.
Ian Lance Taylor replied that the behavior is
undefined, but so far stable. His suggestion was
to open a bug and request that this desirable (!!!)
behavior be explicitly permitted.
Because of the way nested functions are implemented in GCC.
If you call a nested function it has to know the frame address of the containing function in order to refer to its local variables. So if you take the address of such a function the program actually receives the address of a "trampoline": a small sequence of instructions which first loads the frame address and then calls the real function.
The trampoline itself is generated dynamically and putting it on the stack turns out to be cheaper than heap allocating it.
> and putting it on the stack turns out to be cheaper than heap allocating it.
Well, more so that C has no concept of the heap. That's entirely contained within the C libraries. So, the language implementation itself can't do heap allocations (at least, not without sacrificing any chance of using it in embedded or kernel dev situations where you don't have heap allocation, or where you need to use custom allocators)
Having that series of operations produce something useful is unexpected, to say the least.
It's nothing I'd want to see in code that I maintain, but I think you have to give it a bit more credit. Besides that, it's cute :)