[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLEA3oxst2FBDWhC@smile.fi.intel.com>
Date: Fri, 14 Jul 2023 11:01:34 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Alexander Potapenko <glider@...gle.com>, catalin.marinas@....com,
will@...nel.org, pcc@...gle.com, andreyknvl@...il.com,
linux@...musvillemoes.dk, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com
Subject: Re: [v2 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP
On Thu, Jul 13, 2023 at 12:27:15PM -0700, Yury Norov wrote:
...
> > > + void *storage = ea0_storage(handle);
> > > + int size = ea0_storage_size(handle);
> > > + if (!handle || !storage)
> > > + return;
> >
> > You use handle before this check. Haven't you run static analysers?
>
> This approach is called 'defensive programming' as I learned from
> previous iteration.
No, this approach called "let compiler optimize the check away". :-)
When compiler sees something like
TYPE bar = MACRO(foo); // FUNC(foo);
if (!foo)
blalblabla;
the conditional can be eliminated as the optimizer thinks the way "okay,
developer already _used_ the foo in some code, it means it can't not be NULL,
let's drop a dead code".
(Yes, I know what defensive programming means and we actually quite rarely
use it in the kernel for the internal APIs)
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists