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