Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756807Ab3DWPmw (ORCPT ); Tue, 23 Apr 2013 11:42:52 -0400 Received: from mail-ve0-f171.google.com ([209.85.128.171]:59101 "EHLO mail-ve0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756281Ab3DWPmu (ORCPT ); Tue, 23 Apr 2013 11:42:50 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 23 Apr 2013 08:42:49 -0700 X-Google-Sender-Auth: rQbn91iuGe03Al-SShEuhpBwPKs Message-ID: Subject: Re: Unsigned widening casts of binary "not" operations.. From: Linus Torvalds To: David Laight Cc: Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , David Miller , "Theodore Ts'o" , Linux Kernel Mailing List , "the arch/x86 maintainers" , Network Development , "linux-ext4@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 42 On Tue, Apr 23, 2013 at 8:24 AM, David Laight wrote: > > Thinks ... converting: > foo &= ~bar; > to: > foo = ~(~foo | bar); > would generally DTRT. Quite frankly, I'd rather just try to make people (re)move the widening cast. So while foo &= ~bar; is unsafe if bar is narrower than foo, it's unsafe simply because the implicit cast from the C type conversions comes *after* the binary not. An explicit cast fixes it, and shows that you were aware of the issue: foo &= ~(foo_t)bar; and gcc will generate the right logic. Of course, casts then have their own problems, which your thing avoids (as would just having a "andn" operation in C) The best case is for code that does bitmasking ops like this to avoid any casts (implicit or explicit) by just avoiding mixed types. That was, to a large degree, my hope for the sparse patch, but it's nontrivial. Many types are rather "natural" (ie constants have a natural "int" type, sizeof() is size_t, etc) and in other cases you want to do the same ops for two different types (with the case that caused me to start to look at it being the "align to page boundary" for a virtual address vs a PAE phys_addr_t) so you can't really avoid mixing things in some circumstances. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/