Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4617548pxv; Tue, 27 Jul 2021 11:46:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQxi66wvvwjC+Of6cdzYDvWHPXQwEVcjLl223nJqVz4ODNiHtybuGOHmx9OjHlsFsGd52l X-Received: by 2002:aa7:c857:: with SMTP id g23mr28897235edt.100.1627411602451; Tue, 27 Jul 2021 11:46:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627411602; cv=none; d=google.com; s=arc-20160816; b=VWTlPXdonDbGdtv3a6rNCVL8zxz851mTCnLnbn9pDUPPgrSykksr9Kroir85RH08J0 EgMw69IMa5kn72bS+WB1adkCX3834gHYvrXWLy05DEm31I9LnCjBLUSFltJg9K4piFTH WxQA1oBMwdxpNmJ8u+dbl/uWIunHsyFir5WzngtCoYmuwDY6MfMRg7FPRAZdH66wbM0h NCFes7w9ia/8X6SOpZxzhBKmO8fGLcRSeOKAJjIpADSIskXfHdgaaMPhrQoCvZMyKxU1 dmmnZjhDev1q86wynGw8mTmGdAoCG+Jsy2FB1hdJpSM9g8hRq2SZm/mk7UJhDpf4dV4A RK4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=94QBq40SpHOUNaH+/B3/v6p484OyYjSSrQ95EvBqAP8=; b=YDxQD9UfkjQ41rZwWwBthPR/3hOuPHyhQe1VHDlRiXuGs3PBPOYOGzWNB2TBlH5lkX q9GVZuMy1PuvUf5L58jAd/g1rNYvXnj9nZABx5xHM8T4S24U15DcaMGsg9IFPyQQpF3z aEKLtoHP6e9QfoVQMYtPJ/d8ocg8B3X9GujnypfTCjoUAKTkIkLkmSSdSBjajjE6roSl sG0WCCnRSHYhfh03o3RyNSRcsE0UqvSgDaVWOv9lEE+sVJUIjXX5CmZFkNxqowfHgyPA xlg5QAicycJ2g9iOCTl1d22yGYpcepNSquGnW0/TsdELfdJzGRqT3Zj343ELrbGX560t Vs9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=luPjGCY1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y7si3713339eda.558.2021.07.27.11.46.19; Tue, 27 Jul 2021 11:46:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=luPjGCY1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230249AbhG0SpB (ORCPT + 99 others); Tue, 27 Jul 2021 14:45:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:38782 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbhG0SpA (ORCPT ); Tue, 27 Jul 2021 14:45:00 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E2B3B60F9E; Tue, 27 Jul 2021 18:44:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627411500; bh=v57DgBNvmeqirO4JsBMcPzDZ5h2ihzb/QkuymdY559Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=luPjGCY16ahdowVwdbkAR5x4M7Ggpmr/adW5bCBeoda1BQ802QASAcxG+3oGuAtTg yDXM0DKXhHwE7IgJqqbNU26DCBWUmNF18o6zDVrRDIL04Xdyoz4CRf1L8QBdIUbiln XQI0JE2XFBHJDjZYmgCT1pfr1XkaNkHyF0n6kEEs= Date: Tue, 27 Jul 2021 20:44:58 +0200 From: Greg Kroah-Hartman To: Nick Desaulniers Cc: Bill Wendling , Nathan Chancellor , "Rafael J. Wysocki" , clang-built-linux , LKML , linux-toolchains@vger.kernel.org Subject: Re: [PATCH v2 1/3] base: mark 'no_warn' as unused Message-ID: References: <20210714091747.2814370-1-morbo@google.com> <20210726201924.3202278-1-morbo@google.com> <20210726201924.3202278-2-morbo@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 27, 2021 at 11:31:38AM -0700, Nick Desaulniers wrote: > On Tue, Jul 27, 2021 at 10:59 AM Greg Kroah-Hartman > wrote: > > > > On Tue, Jul 27, 2021 at 10:39:49AM -0700, Nick Desaulniers wrote: > > > If there are > > > cases where it's ok to not check the return value, consider not using > > > warn_unused_result on function declarations. > > > > Ok, so what do you do when you have a function like this where 99.9% of > > the users need to check this? Do I really need to write a wrapper > > function just for it so that I can use it "safely" in the core code > > instead? > > > > Something like: > > > > void do_safe_thing_and_ignore_the_world(...) > > { > > __unused int error; > > > > error = do_thing(...); > > } > > > > Or something else to get the compiler to be quiet about error being set > > and never used? There HAS to be that option somewhere anyway as we need > > it for other parts of the kernel where we do: > > write_bus(device, &value); > > value = read_bus(device); > > and then we ignore value as it is not needed, but yet we still HAVE to > > call read_bus() here, yet read_bus() is set as warn_unused_result() > > because, well, it is a read function :) > > Such wrappers are trivial with __attribute__((alias(""))): > https://godbolt.org/z/j5afPbGcM > > At least then it's very obvious if someone adds more call sites to > such an alias. Then that calls for closer inspection in code review > that yes, this is one of those 0.01% of cases. Since they occur 0.01% > of the time, I don't expect such aliases to occur too frequently. That is just, well, horrible. Seriously horrible. Wow. And that is the "documented" way to do this? That feels like an abuse of the already-horrible-why-do-they-do-that-for-variables use of the alias attribute. How badly are compiler people going to complain to me about this if it's in this file? I can take a patch for that, but I feel the comments involved will make people, including myself when I have to look a the code again in 5 years, even more confused... ick, I feel dirty... greg k-h