[cfe-dev] clang comparison webpage

[Alp Toker]

On 09/12/2013 16:24, Chris Lattner wrote:
> On Dec 9, 2013, at 7:50 AM, Alp Toker <alp at nuanti.com> wrote:
> On 08/12/2013 23:20, Mouse wrote:
>>> http://clang.llvm.org/comparison.html compares clang versus three other
>>> compilers, one of them gcc, and invites mail to cfe-dev "if you think
>>> some characterization is unfair here".
>>>
>>> But the comparison to gcc leaves off the major reason clang is a
>>> complete nonstarter for me: lack of support for gcc extensions.  (In my
>>> case nested function support is the biggest one; clang appears to be
>>> under the impression that they are "infrequently used"
>> On this matter specifically, clang is a lot better set up nowadays to parse the old GNU nested functions thanks to work that was done do support closures like blocks and other function declarators that appear in funny places.
>>
>> I just tried and you can get them to parse with a one-line change in clang/lib/Parse/ParseDecl.cpp, and you can get some degree of semantic support for nested variable scope with another small change to ScopeInfo.h and SemaDecl.cpp. Probably with one more tweak to lib/CodeGen you could get this up and running.
>>
>> I think the policy not to support this extension made sense in the early days, but since then we've added support for all kinds of good (and dubious) extensions from GCC, MSVC and others so this is small fry.
>>
>> So if there is a good case for it and someone volunteers their weekend to implement it complete with tests, I can't imagine there would be vociferous objection from current maintainers of the code to be honest.
> Right.  Early on, it just wasn’t important.  Beyond that, I still think that gnu nested functions are bad because 1) the cases that require trampolines on the stack are back for security (needing an executable stack)

So back when I investigated this a few years ago, it turned out a lot of 
people asking for nested functions were in fact just using them as 
syntactic sugar to get local scoping for things like unit tests in C.

We could avoid most of the unpleasant stuff if we restrict support to 
direct calling as I think the trampolines are only needed to take the 
address as a function pointer. Ditto cross-function goto with local labels.

Mouse, would this "safe" but limited implementation of nested functions 
meet your use-case?

If so we can just plug in to the existing closure support, in fact I 
have a really old patch for that lying about somewhere.

>   and 2) because error recovery/QoI is worse with them (in principle) when a } is forgotten.
>
> That said, if someone were motivated to implement this extension (or a subset of it) then that would be really great.  IMO, I just think that -fnested-functions should be off by default.

Agree if this ever happens it should be behind a flag.

Alp.


>
> -Chris

-- 
http://www.nuanti.com
the browser experts