On Mon, Oct 17, 2016 at 01:27:08PM +0200, Vegard Nossum wrote: > On 10/17/2016 11:09 AM, Peter Zijlstra wrote: > >On Mon, Oct 17, 2016 at 11:01:13AM +0200, Jiri Slaby wrote: > >>On the top of that, it's incorrect C according to the standard. > > > >According to the standard non of the kernel has any chance in hell of > >working, so don't pretend you care about that :-) > > I think that's a bit of a false dilemma. It's obviously true that kernel > code does not conform to the standards, but that doesn't mean it's not > something we should strive towards or care about in general. It helps > static analysis tools, compiler diversity, etc. Sure, but this, two separately allocated objects their address should not be compared and therefore... stuff is explicitly relied upon by the kernel in many places. We have workarounds in various places, and this patch adds yet another instance of it. The workaround is simply confusing the compiler enough to have it not do the 'optimization'. But we very much still rely on this 'undefined' behaviour. I think it makes more sense to explicitly allow it than to obfuscate our code and run the risk a future compiler will see through our tricks. I don't see how its different than explicitly disabling the strict-aliasing muck, explicitly allowing (and 'defining') signed and pointer overflow, doing all the concurrency stuff on our own (gnu89 emphatically does _not_ have a memory model) etc.. And given GCC7 is still in development, this might be a good time to get a knob added for our benefit. Are we 'modifying' the C language, sure, but that ship has sailed long ago. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html