[cfe-dev] Why will clang never support all gnu99 extensions?

[David Chisnall via cfe-dev]

On 20 Jul 2017, at 11:54, Dmitry Golovin via cfe-dev <cfe-dev at lists.llvm.org> 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.