

Linux 3.15 Can Almost Be Compiled Under LLVM's Clang - 01walid
http://www.phoronix.com/scan.php?page=news_item&px=MTY2MjY

======
acqq
I like the flexibility of Gcc even if it's maybe slower than clang. And I
really don't support the attitude reflected in this clang error message:

"error: fields must have a constant size: 'variable length array in structure'
extension will never be supported"

Even if something isn't in the standard, if it allows less code to be written,
it is a good thing. My question is then:

Why?

~~~
msbarnett
Clang's user manual has this to say: "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)."

~~~
acqq
Arrays with zero size at the end have completely another semantics. This one
that clang swears to "never implement" allows avoiding explicit alloca calls,
instead the programmer can simply pass the expected size.

It's obviously used in kernel, that's how I discovered about that clang
curiously worded error message: by reading the LLVMLinux site:

[http://llvm.linuxfoundation.org/index.php/Broken_kernel_opti...](http://llvm.linuxfoundation.org/index.php/Broken_kernel_options)

~~~
msbarnett
Yes, zero-length arrays have different semantics; the clang devs weren't
trying to claim they were a drop-in replacement. And, yes, it's obviously used
in the Linux kernel, but the Linux kernel has, traditionally, been wedded to
GCCisms and not cared about working on any other compiler, so the Linux kernel
was not a priority when that decision was made for for that obvious reason.
_Most_ codebases, and certainly the vast majority of codebases likely to ever
target Clang, aren't using this "feature".

Their biggest point was, and remains, that variable length arrays inside
structs _have no defined semantics at all_. GCC _has no design document
specifying their behaviour_. It is impossible to tell what about their
behaviour is undefined happenstance and what is intentional. There is no means
of determining how Clang should behave in any number of corner cases
(presuming you could even enumerate them all), short of reverse engineering
the behaviour of a specific release of GCC, and praying that that release's
implementation was bug-free and displayed no undefined behaviour
(spectacularly unlikely, for a little-used and obscure feature like this).

~~~
acqq
I can specify you the behaviour even if I never looked at sources of that
feature in Gcc, and I'm sure anybody who writes compilers can do the same.
It's nothing earth-shattering, much easier to specify than most of C++
features, and certainly not harder to implement than most of C++.

I see a lot of developers like to ignore C, giving immense priority to C++ and
that makes me sad. C has certainly potential to also get some features first
implemented by major compilers and only then standardized, just like it
happens all the time with other languages.

"Will _never_ be implemented" in the compiler error message is still quite
telling about the climate among the clang developers. Are you one of them?

