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 B709FC433FE for ; Wed, 19 Oct 2022 19:36:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230173AbiJSTg0 (ORCPT ); Wed, 19 Oct 2022 15:36:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229971AbiJSTgW (ORCPT ); Wed, 19 Oct 2022 15:36:22 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2184E1C2E8E for ; Wed, 19 Oct 2022 12:36:21 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id x13so11412573qkg.11 for ; Wed, 19 Oct 2022 12:36:21 -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=oJrk5u73GSSntjHDSFWZPm3W+d2NptLnsl4jnQ6aTBs=; b=dyDRWkQ5VqKw/n/QUOQkovOpnXZICQosgvfGHTMEB24PTjukMWkEQb6WiGZ3AaswEh VYAjmCHm81UDyKGwrRTK4pqVsKdfk4eywGlq59bCDPl2XFFHJiWrSIA1mEV0BH0Um7H8 GojY9blG/jEQqPFxqq14doFT4faiTGwkuzpcw= 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=oJrk5u73GSSntjHDSFWZPm3W+d2NptLnsl4jnQ6aTBs=; b=euwiK6yvB/0xmEm9FMzUZ62rnBK+Tl9o9m/2RtbJIj9r7A+89BARIUbdFYHZ743aY4 XfkMIWBueVNzp+M3/87PgQ12V8YuKzY1c5IZyAKSnnWMSYcQaLUPmc/SJx2VJcO8OsNR FKcwVAgPzMCGAJFB5yT35bSq7suB5oR4UrNI2NwKOIOtwxYzPctYDktGwaFLMXouNcen NRpAQ4s01h7qavIAsginpgkdlplgixo2AZv8htQx+mXrWmr5wtvhaxgBGqEbtVGSgeRh qMzypk+iorWFq6vV3bbeG5YW6SQqkauOHhCr9Q7fOnQs/gxqsaAg7EK7QrKd+/0oJOa3 5GJg== X-Gm-Message-State: ACrzQf30Qul1nmnXEJrvHhnfToX3mQhyQwCZIWG14E+Pfr/+y+N8ZkS8 7nq4N0DvOuKriFATWsAvBoJOj1Jn4cfBew== X-Google-Smtp-Source: AMsMyM4A7CMO6Dxp0UFV7Sv64+mzqk4vD/ddX9tVIhyyEsP9bzVL9SSZvY+4ISk9clzofWr1nHqPQw== X-Received: by 2002:a05:620a:2947:b0:6ee:88c9:bcdc with SMTP id n7-20020a05620a294700b006ee88c9bcdcmr6831811qkp.143.1666208180019; Wed, 19 Oct 2022 12:36:20 -0700 (PDT) Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com. [209.85.128.180]) by smtp.gmail.com with ESMTPSA id i8-20020a05620a248800b006bb0f9b89cfsm5795724qkn.87.2022.10.19.12.36.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 12:36:17 -0700 (PDT) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-354c7abf786so178574087b3.0 for ; Wed, 19 Oct 2022 12:36:17 -0700 (PDT) X-Received: by 2002:a81:1007:0:b0:357:45e3:304c with SMTP id 7-20020a811007000000b0035745e3304cmr8223552ywq.340.1666208177358; Wed, 19 Oct 2022 12:36:17 -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 12:36:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: treat char as always signed To: Andy Shevchenko Cc: Nick Desaulniers , 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 , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 19, 2022 at 12:23 PM Andy Shevchenko wrote: > > > 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. > > At least drivers/media/usb/msi2500/msi2500.c:289 can be converted > to use sign_extend32() I believe. Heh. I didn't even look at that one - I did check that yeah, the MIPS ones made sense (I say "ones", because while my grep pattern only finds one, there are several others that have spacing that just made my grep miss them). You're right, that msi2500 use is a very odd use of bitfields for just sign extension. That's hilariously odd code, but not exactly wrong. And using "signed int x:14" does make it very explicit that the bitfield wants that sign. And that code does actually have a fair number of comments to explain each step, so I think it's all ok. Strange, but ok. Linus