Why will clang never support all gnu99 extensions?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why will clang never support all gnu99 extensions?

Sumner, Brian via cfe-dev
Hi all!

I think this topic was discussed already, but I would like to bring it up one more time. First of all, I like clang and I don't want to insult anyone, I'm just asking about the developer's opinion on why some features are not supported.

Here is a test code for gnu99 standard compliance from elfutils:

    int foo (int a)
    {
      for (int i = 0; i < a; ++i) if (i % 4) break; int s = a; return s;
    }

    double bar (double a, double b)
    {
      double square (double z) { return z * z; }
      return square (a) + square (b);
    }

    void baz (int n)
    {
      struct S { int x[n]; };
    }

Clang prints the following:

    std99.c:8:28: error: function definition is not allowed here
      double square (double z) { return z * z; }
                               ^
    std99.c:9:10: warning: implicit declaration of function 'square' is invalid in C99 [-Wimplicit-function-declaration]
      return square (a) + square (b);
             ^
    std99.c:14:18: error: fields must have a constant size: 'variable length array in structure' extension will never be supported
      struct S { int x[n]; };
                     ^
    1 warning and 2 errors generated.

So the two missing features are the support for nested functions and VLA in struct. There is a bug regarding the first error (https://bugs.llvm.org/show_bug.cgi?id=9206) and it's a WONTFIX. The second error message looks like a lot of people asked to support the feature and also there is and explanation for it in Intentionally unsupported GCC extensions chapter of the documentation: "clang does not support the gcc extension that allows variable-length arrays in structures. This is for a few reasons: one, it is tricky to implement, two, the extension is completely undocumented, and three, the extension appears to be rarely used. Note that clang does support flexible array members (arrays with a zero or unspecified size at the end of a structure)." On the other hand there is another WONTFIX bug (https://bugs.llvm.org/show_bug.cgi?id=4071) that blocks building the Linux kernel. How serious are the developers about their position on intentionally unsupported extensions? What if someone implements support for these extensions and sends in a proper patch? Will it never be accepted?

Regards,
Dmitry
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why will clang never support all gnu99 extensions?

Sumner, Brian via cfe-dev
On Thu, Jul 20, 2017 at 01:54:43PM +0300, Dmitry Golovin via cfe-dev wrote:
> So the two missing features are the support for nested functions and
> VLA in struct.

VLA in struct: This is insane. Think about it. You have *types* with
completely different layout depending on the way code is called. It's a
IMO completely brain dead idea. This is completely different from
flexible array members, where the struct layout remains the same and
only the allocation itself changes. Seriously, remove the commit
privileges to any developer who manages to depend on this extension.

Nested functions: There are two different situations here. With newer
GCC, you can use them as "local" function definition, i.e. moving them
out changes nothing. That's the less insane form, but I'm also only
aware of one project depending on this for non-trivial reasons
(Asterisk's RAII hack). The other form fundamentally depends on stack
trampolines, i.e. memory that is both writable and executable. It should
be obvious why this is a bad idea and why no code should be using it.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why will clang never support all gnu99 extensions?

Sumner, Brian via cfe-dev
In reply to this post by Sumner, Brian via cfe-dev
On 20 Jul 2017, at 11:54, Dmitry Golovin via cfe-dev <[hidden email]> wrote:
>
> There is a bug regarding the first error (https://bugs.llvm.org/show_bug.cgi?id=9206) and it's a WONTFIX.

I think there’s some potential for flexibility here.  There are two places people use these:

1) Where they want some kind of closure.
2) Where they want very-private functions.

In the former case, [Objective-]C blocks and C++ lambdas provide a better solution.  If the function is actually referring to any variables in the enclosing scope, then it requires an executable stack[1], which is a terrible idea for security.

In the latter case, as in this example, the semantics are really a function with internal linkage, but that is only callable from the function where it is declared.  C++ lambdas are often used in this way, but there’s no equivalent for C.  Supporting them in clang wouldn’t be too difficult, but I doubt anyone is particularly motivated to do so.  If someone were to submit a patch, I suspect that there wouldn’t be too much resistance.

> The second error message looks like a lot of people asked to support the feature and also there is and explanation for it in Intentionally unsupported GCC extensions chapter of the documentation: "clang does not support the gcc extension that allows variable-length arrays in structures. This is for a few reasons: one, it is tricky to implement, two, the extension is completely undocumented, and three, the extension appears to be rarely used. Note that clang does support flexible array members (arrays with a zero or unspecified size at the end of a structure)." On the other hand there is another WONTFIX bug (https://bugs.llvm.org/show_bug.cgi?id=4071) that blocks building the Linux kernel. How serious are the developers about their position on intentionally unsupported extensions? What if someone implements support for these extensions and sends in a proper patch? Will it never be accepted?

There are patches for the Linux kernel that remove VLAIS use, so I suspect that it isn’t a compelling example.  This extension is almost impossible to use correctly.  I’m in favour of providing developers with powerful tools, but if you’re going to hand someone a running chainsaw then it’s considered bad form to remove the handle first.  I suspect that there would be significant resistance to this.

David

[1] Technically, you could implement a runtime that provides a set of trampoline buffers for these functions as Objective-C does for the block-as-IMP trampolines, but you’d also need to ensure that they had some cleanup code for destroying them on function exit and that would break if you used longjmp or didn’t compile with exception support, so would be very fragile.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...