Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

I know this isn't the opinion of many kernel developers, but I think a lot of the problems encountered are better solved by removing proprietary GNU C extensions from the kernel code. I would love to start sending patches but I expect they'd just be NACKed.

View on HN

Sounds like this is a prime example where evidence would help. Just thinking "a lot of the problems..." doesn't do much to show why that is the case. Especially without even knowing which extensions you are specifically referring to.

That is, my guess is these extensions are the equivalent of Chesterton's fence. They were introduced for a reason. If you have evidence that that reason is no longer apropros, present the evidence. But don't just complain about the fence.

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.

But, I could just as easily say it is self-evident that the use of proprietary, nonstandard languages extensions was required to get the linux kernel written.

Don't get me wrong, I'm highly amenable to this argument, but it is not an evidence based one.

Now, there could be some easy evidence that would help. For example, evidence that kernels which are built using clang build just as easily using gcc. Or icc. Or ___. That would help. Right off, I do not know if that is the case.

I mean, I said it was self-evident but then provided evidence as well. Here is the evidence:

- Multi-year effort by Clang, a well regarded standards-compliant C compiler, to support the kernel

- Proprietary extensions do not conform to the same strict guidelines for specifications as the C standard and may require reverse engineering to implement correctly

- C is defined by the C specification and Linux is not written in C by this metric

- Therefore, C compilers cannot compile the kernel

Correct me if I'm wrong but I cannot extract similar facts from your comment.

But my counter evidence was that these extensions were required to actually build the kernel. Which is also somewhat self-evident.

So my question to you is if you have evidence that those extensions are not required to actually build the kernel? I get that they are the "sticking" point to moving to clang. But are they also required for the kernel to actually do its job?

I see what you mean. Yes, there are counter examples of kernels that can be compiled without extensions. With my rough knowldge of the Linux kernel in particular, I imagine there are a few places where the use of extensions makes for much better code than without, and for those places the change is of debatable utility. However, extensions are the rule rather than the exception for the kernel. The bulk of the kernel could be written without them.

Unix managed to be written without those extensions.

Which one? And did it successfully compile with multiple compilers?

> Which one?

UNIX, the genesis of C and all that derived from AT&T original code.

> And did it successfully compile with multiple compilers?

Any that was K&R C compatibile.

GCC was a toy compiler not used for any serious UNIX development until Sun decided to start selling the SDK as part of a SunOS developers edition, quickly followed by other UNIX vendors.

So by definition, until GCC became an usefull project, there were no UNIX kernels written with GCC C extensions.

So, I would have understood if you said the original AT&T UNIX. I've always heard the term used to cover the entire family. And, I honestly had no clue whether or not the likes of SunOS/HP-UX/etc were compiled with multiple compilers. My understanding was each typically came with their own compiler.

FreeBSD can be built with gcc, although it's built with clang by default: https://wiki.freebsd.org/BuildingFreeBSDWithClang

The patches to make it work for icc is simple enough that this is almost a non-issue: https://lists.freebsd.org/pipermail/freebsd-arch/2003-Novemb... (albeit old)

An inability to compile on nothing but GCC is a feature for a lot of zealots out there.

Reply on news.ycombinator.com