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 A489DC433FE for ; Wed, 19 Oct 2022 17:26:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229787AbiJSR0e (ORCPT ); Wed, 19 Oct 2022 13:26:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229648AbiJSR0b (ORCPT ); Wed, 19 Oct 2022 13:26:31 -0400 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76B581C0708 for ; Wed, 19 Oct 2022 10:26:28 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id z11-20020a05683020cb00b00661a95cf920so9899229otq.5 for ; Wed, 19 Oct 2022 10:26: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=cupPL1neXJFDi/CczZUnnSksrOf8QPniSG3CPoyTvwk=; b=Gac78J9i90UOUBCVrylc5ZrTgnCY15Gnsk7zaNO8hbQdMniRSpKeWxkTTG5TuRyEZB UDik7FL9jFr1ZdlcLkLkZx9hlXsSPXv05eXESmVQoWZJDrDoiml8TtqDCjSsxyMM3DcH ByvbBAe5KO9N+pJ+tA8JESSDV1WDzdBhegWb0= 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=cupPL1neXJFDi/CczZUnnSksrOf8QPniSG3CPoyTvwk=; b=PoS+eHVLG0N2KcXtZ4Cc1iqhiTc2p1cIFFH8Ry7/6N+eB4m6UMLrRHWX/1qcNBYjL+ b+aeXKas4qtHgHyK1UH+xM+2odz9jQjf3PCQGEyJExDk8+w8AssGSY8aENT6cb4AKhQJ 9Zm0Mo+g2Km5rsnmbsAZgn0DiXcfJ3MUcySf8CSpA0a2PmFW+TidgNAbqMoCqMsyMQt6 oIbGx2Xuz8se5Y/LEuD7ajenOQZ+h0Q3ICc9NrB7foI1hSEltCyIsZXXWabkVpmqLMxE VXWwd3XqAjWd6CHZ2aWvB9KTCPBBH/8GJnlaXxPeT0pRTOleA4UvIeFdI0hpraplnvtt +uRQ== X-Gm-Message-State: ACrzQf29VDraUqIy2lglshZj4a3GaGNftZ/6hLRVZSVr5AO+8fZJ1qRN lfwPwQ37o4lbm435c8LvsWqlJz5y6A8slQ== X-Google-Smtp-Source: AMsMyM7SZShIs9O9NceAa+k82KLulh/2dc6thv5XBNgFzZFVn3whu9j7h35HxiQ1+2gCEmi9YAu9pQ== X-Received: by 2002:a9d:74c6:0:b0:661:c309:f0cf with SMTP id a6-20020a9d74c6000000b00661c309f0cfmr4407337otl.55.1666200387204; Wed, 19 Oct 2022 10:26:27 -0700 (PDT) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com. [209.85.167.176]) by smtp.gmail.com with ESMTPSA id e9-20020a9d2a89000000b006618b96bcd4sm7221081otb.52.2022.10.19.10.26.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 10:26:25 -0700 (PDT) Received: by mail-oi1-f176.google.com with SMTP id g10so20015631oif.10 for ; Wed, 19 Oct 2022 10:26:25 -0700 (PDT) X-Received: by 2002:a54:4899:0:b0:354:add8:52ab with SMTP id r25-20020a544899000000b00354add852abmr5135777oic.229.1666200385369; Wed, 19 Oct 2022 10:26:25 -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 10:26:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: treat char as always signed To: Segher Boessenkool Cc: "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-kernel@vger.kernel.org On Wed, Oct 19, 2022 at 10:14 AM Linus Torvalds wrote: > > The pointer-sign thing doesn't actually help (ie it won't find places > where you actually compare a char), and it causes untold damage in > doing completely insane things. 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. I failed miserably. You actually can see some signs (heh) of that in the sparse sources, in that the type system actually has a bit for explicitly signed types ("MOD_EXPLICITLY_SIGNED"), but it ends up being almost entirely unused. That bit does still have one particular use: the "bitfield is dubiously signed" thing where sparse will complain about bitfields that are implicitly (but not explicitly) signed. Because people really expect 'int a:1' to have values 0/1, not 0/-1. But the original intent was to find code where people used a 'char' that wasn't explicitly signed, and that then had architecture-defined behavior. I just could not come up with any even remotely sane warning heuristics that didn't have a metric buttload of false positives. I still have this feeling that it *should* be possible to warn about the situation where you end up doing an implicit type widening (ie the normal C "arithmetic is always done in at least 'int'") that then does not get narrowed down again without the upper bits ever mattering. But it needs somebody smarter than me, I'm afraid. And the fact that I don't think any other compiler has that warning either makes me just wonder if my feeling that it should be possible is just wrong. Linus