[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdkbgr5uPBUC815nrJ_-fHQD2KEYmZ0E8qZRBLL9uQ2WFw@mail.gmail.com>
Date: Tue, 27 Jul 2021 11:31:38 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Bill Wendling <morbo@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-toolchains@...r.kernel.org
Subject: Re: [PATCH v2 1/3] base: mark 'no_warn' as unused
On Tue, Jul 27, 2021 at 10:59 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> 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.
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists