From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9C38C43217 for ; Wed, 19 Oct 2022 18:36:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230030AbiJSSgq (ORCPT ); Wed, 19 Oct 2022 14:36:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230052AbiJSSgn (ORCPT ); Wed, 19 Oct 2022 14:36:43 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EC8D188A8B for ; Wed, 19 Oct 2022 11:36:28 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id mg6so11971951qvb.10 for ; Wed, 19 Oct 2022 11:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2Hic1oazVXE3zC6bxc7l73SbPyyOlgvu3WnXoJo8Sr0=; b=V01kWhoyFvXQa88Ht6WMjphqL1lN6byPpIbIDK3W41MOcgbJDpKD3vxULheyUZmTEp NCBfyrQsWYEt4tLS+X7KE/eUBywCcBY3ZYljTQ1vY5HfXulKEcutsetsAU7Ix8M39MTK fCzZzPaGLPvKqaL5Po7CO+2Wzkt5AlEOjbhmc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2Hic1oazVXE3zC6bxc7l73SbPyyOlgvu3WnXoJo8Sr0=; b=Mp3jzYPR87OTfCkHKNAboqGyeFr7iNuSTxHR858U6Yq0k1dJHuqSIRizgJkdltQMWx sqjPeS1EO8Mzn/Tcvrg2lNpvuyBX88ZF7k+ahoYynZmrFu8WkME1FSuwXnd19jKHAWYA FGObniL2jItcApJD9Y+3om5z/wgr2YR8tOaNxMvo0qCsAjEn/rlBa35vibBAqjI2BA3W DUmJIji8WKmEHIs/Bv1/LDDGSECjv//L2jqC5MufKBDQ72kqy0UfgW2g4StJSw9YR0j3 TF1bEutJ5+0lnE/Pli71hcQo/N+7dP9sX9vgp1FPli51Z5/cZsX5w6iqroJ494EBRL4O dmBg== X-Gm-Message-State: ACrzQf2B4T8s+XjsNeiGFrgJ6rAmqZ1bfL6ybe3+4jwU3Oi1dQprNo+P XuzOH0sS8jy6P/ViqcWE0JPi4BfippWh6A== X-Google-Smtp-Source: AMsMyM5VS19oHr2pOi9GNBfroyGzk3k+vlrCaL0vQQM/kHNlHKgwtzmJXPW8ojfxp3uFZn6Ft2K/9w== X-Received: by 2002:a05:6214:20ed:b0:4b1:cace:31ed with SMTP id 13-20020a05621420ed00b004b1cace31edmr8115974qvk.58.1666204569364; Wed, 19 Oct 2022 11:36:09 -0700 (PDT) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id y22-20020ac87096000000b0035cd6a4ba3csm4493116qto.39.2022.10.19.11.36.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 11:36:07 -0700 (PDT) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-3608b5e634aso176613717b3.6 for ; Wed, 19 Oct 2022 11:36:07 -0700 (PDT) X-Received: by 2002:a81:2544:0:b0:360:c270:15a1 with SMTP id l65-20020a812544000000b00360c27015a1mr7629450ywl.67.1666204566848; Wed, 19 Oct 2022 11:36:06 -0700 (PDT) MIME-Version: 1.0 References: <20221019162648.3557490-1-Jason@zx2c4.com> <20221019165455.GL25951@gate.crashing.org> In-Reply-To: From: Linus Torvalds Date: Wed, 19 Oct 2022 11:35:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: treat char as always signed To: Nick Desaulniers Cc: Segher Boessenkool , "Jason A. Donenfeld" , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-arch@vger.kernel.org, linux-toolchains@vger.kernel.org, Masahiro Yamada , Kees Cook , Andrew Morton , Andy Shevchenko , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, Oct 19, 2022 at 11:10 AM Nick Desaulniers wrote: > > On Wed, Oct 19, 2022 at 10:26 AM Linus Torvalds > > > > Side note: several years ago I tried to make up some sane rules to > > have 'sparse' actually be able to warn when a 'char' was used in a > > context where the sign mattered. > > Do you have examples? Maybe we could turn this into a compiler feature > request. Having prior art on the problem would be a boon. It's been over a decade since I seriously worked on sparse (Hmm. Probably two, actually). And I never got the 'char' logic to work well enough for it to have ever made it into the kernel. I'm also fairly sure I did it wrong - if I recall correctly, I did it on the type system level, and the logic was in the tree simplification, which was always much too weak. Sparse does *some* expression simplification as it builds up the parse tree and does all the type evaluations ("evaludate.c" in sparse), but most of the real optimization work is done on the SSA format. So what I probably *should* have done was to have a special "BEXT" opcode (for "byte extend", the same way sparse has ZEXT and SEXT for well-defined integer zero extend and sign extend), and linearized it with all the simplifications that we do on the SSA level, and then if the BEXT opcode still exists after all our optimization work, we'd warn about it, because that means that the signedness ends up mattering. But sparse originally did almost everything just based on the type system, which was the original intent of sparse (ie the whole "extend the pointer types to have different address spaces" was really what sparse was all about). > Clang's -Wbitfield-constant-conversion can catch that. Yeah, so bitfield signedness is really trivial, and works all on the type system. It's very easy to say: "you defined this member as an implicitly signed bitfield, did you *really* mean to do that?" because signed bitfields simply do not exists in the kernel. So that warning is trivial, and the fix is basically universally change 'int a:1' to 'unsigned a:1', because even *if* you do want signed bitfields, it's just better to make that very very explicit, and write it as 'signed int x:10'. We do have a couple of signed bitfields in the kernel, but they are unusual enough that it's actually a good thing that sparse just made people be explicit about it. Do git grep '\.*:[1-9]' to see the (few) examples and a few false positives that trigger in the trace docs. So sparse doesn't actually have to be clever about bitfield signs. It can literally just say "did you really mean to do that", and that's it. Very simple. Not at all the complexity that 'char' has, where every single use technically tends to cause a sign-extension (due to the integer conversion), but that doesn't mean that it *matters* in the end. Linus