Android kernels are built with Clang. So really it's just missing support for MSVC, for obvious reasons.

For now, at least [1][2]. See the rest of that thread.. llvm guys really don't want asm goto, and kernel really wants it.

[1] https://lkml.org/lkml/2018/2/14/724 [2] https://lkml.org/lkml/2018/2/14/157

Well, yeah, that's what the other commentators here misunderstand. Sure the kernel is C, but a non-optional part is assembly in various forms that obviously is not standardized between compilers. So it takes effort to support kernel building. Google paid up and made that happen.

Clang was made to support GCC extensions and be as close to a drop-in replacement for GCC as possible. Linux misses support for MSVC, Intel C Compiler, XL C and basically every other C Compiler ever written except for these 2.

Clang doesn't support every GCC extension, though. For example, nested functions is something that it doesn't do.

Yup. And that one is a deal-breaker for me.

Nested functions is exactly how you would write it in assembly.

Does anyone know why clang won't support them? "Blocks" are fucking stupid.

Because throwing a trampoline on an executable stack is a hack and a glaring exploitation vector.

http://lists.llvm.org/pipermail/cfe-dev/2015-September/04503...

Straw man.

GCC doesn't use a trampoline for the following code:

    long f1 (void) { long i = 0; void f2(void) { i++; } f2(); return i; }
    int main() { return f1(); }

So maybe David Chisnall doesn't know what he's talking about? Or maybe he's talking about a specific use case further up the thread. I'm not going to speculate.

But to edify on my "Blocks" are fucking stupid throwaway, in clang you can do this:

    long f1 (void) { __block long i = 0; void (^f2)(void) = ^{ i++; }; f2(); return i; }
    int main() { return f1(); }

which is close enough I could almost paper over the syntax differences with macros, but clang produces unnecessary allocations(!) which are completely unacceptable for my targets and make clang unworkable for me -- even if I could stomach the dogshit assembly that clang produces during testing and continue to use gcc on the packaging server.

Surely clang could simply disallow passing the address of the nested function, if it's trying to protect people from themselves?

And Borland Turbo C, don't forget it.

MSVC doesn't support all of C99 anyway.

There's no such (real, usable) language as 'standard C'.

Nothing is really written in "standard C".