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).
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?
Comments
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).
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?