Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4673574pxv; Tue, 27 Jul 2021 13:22:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7eJk0nk+eYnmiQasV2gToabThOj9ypKgr3vuAM35VZyJ0ppS5+g/LZPKyOe36bk8vACtj X-Received: by 2002:a05:6e02:1905:: with SMTP id w5mr18265325ilu.270.1627417350213; Tue, 27 Jul 2021 13:22:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627417350; cv=none; d=google.com; s=arc-20160816; b=wstFe4TcZRUepcAA2tFD7alv4SPwYnCaOYEL/Ja8m7QZMS7dafOMVsX4wWHQQZigfo Lhw92VMsjoCnmUHEOMPteT3ehI9sF53T7YX1jbACcTle7t+CpE+7MiXyxdkZE+YT+Z/7 EchA1uOI65dErZQsZEb1w0FbnJW0p5scVtEohIFNiOmWN5wn7T5HQlfeuQxImFmh9fip 9eObNrv/iIheSSER7FoTJN4gihkNAUUstOV/AdnXdj4B3CViLYnRKveKLBFKDtFXQP7I AyKXh5EW8s+dgFMz3XVKVqgWxwOLFk+WqpHSJ4qATgDBC1ukSo6hrt8NhIhV0eiYyMth DPFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=OUF6YpFqjle/wEU+YyvqiwgXbhiy7OL7/NvwhyoQHNY=; b=NXrX5OHjt5ptc87z8FjOoWdvywBmS+EkkCvi7SeXlxfoSrZJ7yj4W8Zg++Hh8/TFaA vTgkan9cXOTRLIlWGuAGxMvYWmftIuDyM5O6M0V382eOFR0rUfjGsJAwO90OKAt+52Ty VuOEboPatPixihmjA0zNiaztKjQkx/nWsoAHV3n6QPNRvTizO1yAx6NzE21juI8g8OCB 9HVDq2Tr8xfT89YN0Bt5uoXIGw6T4V+qZXfCKPW2FbWulGUpY5rpGW2I76Y1ufeVZIUg AxyoyZ3UJ+Fl1HKpaVEiEpC37kHBq9JPxTQh3okABJ/ZA3VnCjsuLnpeBep8t/WaaAaE hN7A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n14si4978567ilk.78.2021.07.27.13.22.18; Tue, 27 Jul 2021 13:22:30 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232374AbhG0UVR (ORCPT + 99 others); Tue, 27 Jul 2021 16:21:17 -0400 Received: from gate.crashing.org ([63.228.1.57]:52631 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232344AbhG0UUk (ORCPT ); Tue, 27 Jul 2021 16:20:40 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 16RKDTXL032385; Tue, 27 Jul 2021 15:13:29 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 16RKDS4x032383; Tue, 27 Jul 2021 15:13:28 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 27 Jul 2021 15:13:28 -0500 From: Segher Boessenkool To: Greg Kroah-Hartman Cc: Nick Desaulniers , 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: <20210727201328.GY1583@gate.crashing.org> 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: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 27, 2021 at 07:59:24PM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 27, 2021 at 10:39:49AM -0700, Nick Desaulniers wrote: > > I think warn_unused_result should only really be used for functions > > where the return value should be used 100% of the time. > > I too want a shiny new pony. > > But here in the real world, sometimes you have functions that for 99% of > the users, you do want them to check the return value, but when you use > them in core code or startup code, you "know" you are safe to ignore the > return value. > > That is the case here. We have other fun examples of where people have > tried to add error handling to code that runs at boot that have actually > introduced security errors and they justify it with "but you have to > check error values!" > > > 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? The simplest is to write if (do_thing()) { /* Nothing here, we can safely ignore the return value * here, because of X and Y and I don't know, I have no * idea actually why we can in this example. Hopefully * in real code people do have a good reason :-) */ } which should work in *any* compiler, doesn't need any extension, is quite elegant, and encourages documenting why we ignore the return value here. Segher