Received: by 2002:a05:622a:251a:b0:39a:b4a2:e86 with SMTP id cm26csp675578qtb; Wed, 19 Oct 2022 11:53:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Syqxx+xhpURjo9MgWDj5p5zPpS6EtCjir+ZEJhmsX695jEXWBSPNETJ2yWdyB/h6tYAGA X-Received: by 2002:a05:6402:22ed:b0:458:bcd1:69cf with SMTP id dn13-20020a05640222ed00b00458bcd169cfmr8973890edb.260.1666205594394; Wed, 19 Oct 2022 11:53:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666205594; cv=none; d=google.com; s=arc-20160816; b=SwVeCJZPC2Kj7hUr2B9eFBkgJCnccuGbEYFw/QOjReLeIvf2fq+XEVqkmhyK+GpjjQ 1BtlNiVGO8xdKFw7MaesvLSyOJKsY4/G9qE7uPC/UEbTOsUCjT2vE7/DuPfNPk6UZA7a +XubGBa6j4qFIosKV0EdujFHvd01o8fpIxTPxhDYLfh2YS1+VekhymEGpqtYcCiVKB/y ddfcRAIjP7l0ylefall/Q+QLAyNsesqwKDrlTdgeO+wYXn+S6x30iAsysZutkzWuy+tE ng3AXvEcKRxe3srRAqt41bq243nTgWsOQWlKUlIzcT0NxN9cLSlYHQScjyi783RViubr UxDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=h1RcL8BPrrn0ZTMAZgdWymleKVlN0GVlF2LLrZfELFo=; b=zv05rpfEBVJfllVhQ16aPXRujyQTjWxRbt08O9ahbaVdTYcSQA5tSGAJxwSQeQ+34t hg4zCLkviSed44/S9wUTpPDOuufJ3o7xkGLuG3ZwUb6IAOTI+Q7ChYAJ26NTpCDy834Z WKISUSXl841j87ky+h9X4bY7CBPCTVMtVxer3bCYTybwARxStPhd+LvxRjxx1pTHoyYn CUn8i1SI8ANuu8kKZV4nrCP9vxRkrBGrXBkhWqz5b555gd8OV9GIK3UOzyA06TEBqBQa VA+/sE1VR4Fu2stqmj38EzfsNqtpPgLLaA/uAZaI9/axPMCL0NIAZNcrv0Fx4BT7JwTQ 7IjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FfoVpW9M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp14-20020a1709071b0e00b0078198611a45si14220467ejc.980.2022.10.19.11.52.48; Wed, 19 Oct 2022 11:53:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FfoVpW9M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230368AbiJSSVY (ORCPT + 99 others); Wed, 19 Oct 2022 14:21:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230233AbiJSSVV (ORCPT ); Wed, 19 Oct 2022 14:21:21 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D4BB59717 for ; Wed, 19 Oct 2022 11:21:21 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id y72so20217100oia.3 for ; Wed, 19 Oct 2022 11:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=h1RcL8BPrrn0ZTMAZgdWymleKVlN0GVlF2LLrZfELFo=; b=FfoVpW9MKQr/IY4n02JjJbEh3PPjuWKUkQNWyKfLWg6Mm7D6GF2jkSWT1a9oPRh51Z Wed2BjOT3ZUQKsXj6kOMo3sIAm9dEPTKrK7GqcT+1L5v8L+fwtRrC88unTMpHnWJr/A0 DnTjnpp1obnUbdnNcA9UZjol2Nd6zKbe/fonWgv2E+xgM04QeT1tJZ760kicMekHqMmb rIpR3bgauPdOGF0rTXy41v7v/lzaGeAW9IZEBvCWUEXz9lnO9btJxS86bnUC8SnsOpN2 7ceVlVMdz+wWOpYdiMGQCP/9n/x2hDAvyySpHDfywp0l3kJyDVYQu3ziOkro9NBFiK2W o3CQ== 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=h1RcL8BPrrn0ZTMAZgdWymleKVlN0GVlF2LLrZfELFo=; b=kowD/eKQX6JCFdtjDYIc07OahpXUcPJARyf8/uSi7k13gwUEHzWF6QrphXqACAkrNG k97prGXDAeX2SSbD2sUAv8hlMYtihvJREJ4jM+9BHVjx6AcOHGntA27DudJEbnOkMKMw 4u+RmcYeP4/Y9BF9B7Xfl7EOd064ezjawClgWazfh+2mUXkLVVIgs0Z9NaaFVDbWMoCI L9TLHIrrl7BjaPLnC31XijsNQ2ZcCLVSBq4QL1VLFQ8C4NvICN3BdexVgmWAOZPn0t/q LLQ0gn+Sn73ho5kBH5fNqfd05gqvFnu+/L168N8A2xbWRU+E9XIYnQkBMPsb1bFHSylW mlNA== X-Gm-Message-State: ACrzQf2OybxkUWgHF2C8p06y6Sycj7MkQ9s8rqvZIzKnDq6usKt4ig2m 0KLTswAJC6udwwmPE/EdtHCjF/MDhYVTxPWLph3hEVAd670= X-Received: by 2002:a17:90b:3a88:b0:209:f35d:ad53 with SMTP id om8-20020a17090b3a8800b00209f35dad53mr46571979pjb.102.1666203669615; Wed, 19 Oct 2022 11:21:09 -0700 (PDT) MIME-Version: 1.0 References: <20221019162648.3557490-1-Jason@zx2c4.com> <20221019165455.GL25951@gate.crashing.org> <20221019174345.GM25951@gate.crashing.org> In-Reply-To: From: Nick Desaulniers Date: Wed, 19 Oct 2022 11:20:58 -0700 Message-ID: Subject: Re: [PATCH] kbuild: treat char as always signed To: Linus Torvalds 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 19, 2022 at 11:11 AM Linus Torvalds wrote: > > But while sparse does a lot of basic optimizations, it still left > enough "look, you're doing sign-extensions on a 'char'" on the table > that it warned about perfectly valid stuff. > > And maybe that's fundamentally hard. > > The "-Wpointer-sign" thing could probably be fairly easily improved, > by just recognizing that things like 'strlen()' and friends do not > care about the sign of 'char', and neither does a 'strcmp()' that only > checks for equality (but if you check the *sign* of strcmp, it does > matter). > > It's been some time since I last tried it, but at least from memory, > it really was mostly the standard C string functions that caused > almost all problems. Your *own* functions you can just make sure the > signedness is right, but it's really really annoying when you try to > be careful about the byte signs, and the compiler starts complaining > just because you want to use the bog-standard 'strlen()' function. > > And no, something like 'ustrlen()' with a hidden cast is just noise > for a warning that really shouldn't exist. > > So some way to say 'this function really doesn't care about the sign > of this pointer' (and having the compiler know that for the string > functions it already knows about anyway) would probably make almost > all problems with -Wsign-warning go away. > > Put another way: 'char *' is so fundamental and inherent in C, that > you can't just warn when people use it in contexts where sign really > doesn't matter. A few times in the past, we've split a warning flag into a group so that we could be more specific about distinct cases. Perhaps if -Wpointer-sign was a group that implied -Wpointer-char-sign, then the kernel could use -Wpointer-sign -Wno-pointer-char-sign. I don't know if that's the right granularity though. -- Thanks, ~Nick Desaulniers