http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet
"clang does not support nested functions; this is a complex feature..."
That is bitter sweet. I need it because a library I'm building uses
them (but I'd prefer the library not use them).
The devs might consider adding text to the statements: in addition to
being complex, it also breaks No-Exec Stacks because a trampoline is
placed on the stack (assuming Clang would have a similar
implementation to GCC). I think the security posture is more important
than feature complexity 
And the devs might consider adding this text to the statements: Clang
has no plans to implement the feature. See Bug 6378,
http://www.llvm.org/bugs/show_bug.cgi?id=6378.
From: "Jeffrey Walton" <noloader@gmail.com>
To: cfe-dev@cs.uiuc.edu
Sent: Friday, July 25, 2014 11:43:05 AM
Subject: [cfe-dev] User manual, and GCC functions not implemented
http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet
"clang does not support nested functions; this is a complex
feature..."
That is bitter sweet. I need it because a library I'm building uses
them (but I'd prefer the library not use them).
The devs might consider adding text to the statements: in addition to
being complex, it also breaks No-Exec Stacks because a trampoline is
placed on the stack (assuming Clang would have a similar
implementation to GCC). I think the security posture is more
important
than feature complexity
And the devs might consider adding this text to the statements: Clang
has no plans to implement the feature. See Bug 6378,
http://www.llvm.org/bugs/show_bug.cgi?id=6378.
Not that I'm advocating implementing it, but I wonder if now that we have support for many similar constructs (C++ lambdas, OpenMP outlining, etc.) it would not be as complex as it once was.
-Hal
I *think* there may be a work around for me using Objective C style
blocks in C mode. A fellow on Stack Overflow suggested it at
c - Rewrite GCC cleanup macro with nested function for Clang? - Stack Overflow.
Perhaps the manual could be updated to also include text about using
Objective C style blocks, too.
Hi Jeffrey,
It'd be great if you could submit a patch to the document. Indeed,
"this is a complex feature" is not *at all* the reason why it's never
going into Clang.
When reviewing your patch, I hope other people will chime in and give
their reasons why that's a bad idea and we'd have a *much* better
document.
Thanks for looking into this.
--renato
Hal,
It's not about code complexity, it's about semantics.
Nested functions play with scopes, which are rigorously defined by the
standard, and access to internal variables can be a mess when you
start mixing up stuff. The standards committees made it pretty clear
that nested functions are a no-no and I'd bet on their wisdom more
than on a random library writer's any day.
A better strategy would be to cry foul to the library writers and ask
them to conform to the standard, since other projects rely on their
library.
cheers,
--renato
I guess this includes some random compiler implementer who thought
it'd be a neat idea to support nested functions in the first place 
Csaba
I don't know how nested functions (or VLAIS) got into GCC, but I bet
it wasn't a bored compiler engineer that thought it was cool. More
likely it came as a pressure from a large user group, such as the
Linux kernel, and GCC, in their early ages, had to abide.
I don't know a single compiler engineer, LLVM, GCC or proprietary,
that strongly defends nested functions or VLAIS. But deprecating
functionality is a lot harder than adding it, and that's why I
advocate for collaboration between GCC and LLVM, so that we can get
multiple points of view and also support from both fronts. Strongly
denial from either side is what's going to remove those "features"
from both compilers.
cheers,
--renato