Linux Kernel contains only C code?

[greg@kroah.com (Greg KH)]

On Mon, Jan 29, 2018 at 01:00:10PM -0500, Jeffrey Walton wrote:
> On Mon, Jan 29, 2018 at 12:33 PM, Greg KH <greg@kroah.com> wrote:
> > On Mon, Jan 29, 2018 at 12:16:19PM -0500, Jeffrey Walton wrote:
> >> ...
> >> It would be nice if they moved away from UB and implementation defined
> >> behvior, but sometimes the political problems are heavier than the
> >> technical solutions.
> >
> > What do you mean by this?  What "UB" does the kernel rely on that
> > prevents compilers from properly building it?  We do have some pretty
> > strict requirements in the kernel for a compiler, but anything "odd" is
> > usually just a bug and we are always willing to take patches to fix
> > them.
> 
> https://groups.google.com/forum/#!topic/linux.kernel/-VzG6FWZiy8 and
> https://www.spinics.net/lists/linux-crypto/msg19466.html .
> 
> I found the first one from 2013 amusing:
> 
>   JW >> According to Section 5.8, "Shift Operators" of
>   JW >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf:
>   JW >>  "The operands shall be of integral or enumeration type ...
>   CL > The kernel doesn't try to be fully standard conformant.
> 
> The second one from 2016 was disappointing. It suggested a standards
> compliant rotate that was constant time for the linux-crypto folks.
> That was rejected by some:
> 
>   PA >> So you are actually saying outright that we should sacrifice *actual*
>   PA >> portability in favor of *theoretical* portability?  What kind of
>   PA >> twilight zone did we just step into?!

Well, let's not get into the crazy crypto code in the kernel, it's not a
good example of much these days :)

> Its kind of like I said... the political problems are harder than the
> technical solutions.

Those should now all be gone, thanks to some persistent developers.
clang builds the kernel just fine as I mentioned, and if you look close,
people are working to get something other than 'ld' to link it as well
:)

thanks,

greg k-h