Building the Linux kernel with clang (lwn.net)

Maybe he's talking about the sanitizers? eg: https://clang.llvm.org/docs/AddressSanitizer.html

the static analyzer, along with all the other checks available from clang-tidy: https://clang.llvm.org/extra/clang-tidy/checks/list.html

flexible array member ≠ variable-length array

See: https://news.ycombinator.com/item?id=15303211

This would be a really useful feature in C if it was made more general, even if the scope of the definition remained limited. But with GCC 7

  struct { int arr[n]; } s = { 0 };

gives

  error: variable-sized object may not be initialized

And

  (struct { int arr[n]; }){ 0 }

gives

  error: compound literal has variable size

GCC still doesn't even permit a simpler compound literal like (int[n]){ 0 }. I understand that compound literals and VLAs are distinct, and that the above limitations are, strictly speaking, consistent with the standard constructs. But I would think that once you have variable-length struct members that it wouldn't be too difficult to unify the semantics of VLAs and compound literals. If GCC can't be bothered to improve language consistency, then that's pretty strong evidence that VLA struct members are a dead-end and I can't fault clang for avoiding it.

But if GCC did improve consistency, it might significantly help push C toward safer array semantics. The last hurdle would be definition scope and working out how declarations worked. Presumably the ABI would require fat pointers that embed VLA annotations. Getting there would be a long, winding road, but this is how it would happen. It's complex, but the cost+benefit ratio would, I think, be better for both compiler writer and programmer compared to the complexity of C++.

thanks. that makes sense.

    #include <stdio.h>
    void foo (int n) {
      struct S { int x[n]; int y; };

      printf("offset: %ld\n", __builtin_offsetof(struct S, y));
    }

    int main() {
      foo(2);
      foo(16);
    }

    offset: 8
    offset: 64

"will never be supported" I wonder how many times you have to be asked before you put that in the error message.

I didn't know...

https://libcxx.llvm.org/

But according to what I see on that page, my interrogation remains : once the kernel is built without gcc, then GNU's power will fade away.

GPL and HTML have, in their own ways, enforced that some important code remains open (and sharable and modifiable). By weakening them, the openness will be weakened too.

Of course it won't be 1000 years of darkness, but well, it makes me a bit sad :-)

OpenBSD is also now building the kernel/userland and most of the ports tree with Clang for i386/amd64 and arm64. 6.2 will ship with it as the default system compiler.

> Kroah-Hartman said that he wished there was a competitor to the Linux kernel.

Linux people refuse to look outside their vacuum chamber.

You may have background knowledge.

It's about a kernel for which compiling with Clang is (1) interesting and (2) novel. If you know Linux, you'll recognize that's Linux.

Thanks!

What about Little Wicked Newsletter?

Context:

In the C community, undefined behavior may be humorously referred to as "nasal demons", after a comp.std.c post that explained undefined behavior as allowing the compiler to do anything it chooses, even "to make demons fly out of your nose".

https://en.wikipedia.org/wiki/Undefined_behavior

I mean, the problems faced by compiling the kernel with Clang (or any other standards-implementing C compiler). The problems are pretty easy to find, just look at the relevant commits in Clang and Linux. The main problem Clang faced with the kernel was lots of use of GNU C extensions everywhere.

I think it's self-evident that the use of proprietary, nonstandard language extensions is a bad idea. It leads to multi-year efforts getting other compilers to support "features" that aren't in the spec (and as a result, are typically underspeced by the compilers that implement them and require reverse engineering to fully understand and implement correctly). Linux isn't written in C, it's written in some other language that's deceptively similar to C. It should be enough to write a compiler that accurately implements the C standard to compile the kernel with.