From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: linux-next: build warning after merge of the tip tree Date: Fri, 18 Jul 2014 13:50:39 -0700 Message-ID: <53C9889F.3040107@zytor.com> References: <20140718150005.73db8eb9@canb.auug.org.au> <53C97287.5020509@zytor.com> <53C97E0F.6090601@zytor.com> <53C98055.5070301@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from terminus.zytor.com ([198.137.202.10]:43775 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762161AbaGRUvX (ORCPT ); Fri, 18 Jul 2014 16:51:23 -0400 In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Stephen Rothwell , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , "linux-next@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linus Torvalds On 07/18/2014 01:20 PM, Andy Lutomirski wrote: >> >> The reason this is a concern is that: (x > x + n) and its variants is >> often used to mean (x > INT_MAX - n) without the type knowledge, but >> that is actually invalid standard C because signed types are not >> guaranteed to wrap. > > Right, but the constant in this case is *much* less than INT_MAX. > Anyway, this is moot. It isn't about the constant (n) at all, it is about the value of x. > I do wonder whether the kind of people who build hardened kernels > should enable -fwrapv, though. -fwrapv in gcc makes signed arithmetic strict 2's-complement, which is what I think we want in the kernel. Someone would just have to make sure there isn't some key codepath in the kernel which gets pessimized. -hpa