[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLad7sFvQ3rEDN5o@smile.fi.intel.com>
Date: Tue, 18 Jul 2023 17:13:02 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: catalin.marinas@....com, will@...nel.org, pcc@...gle.com,
andreyknvl@...il.com, linux@...musvillemoes.dk,
yury.norov@...il.com, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com,
syednwaris@...il.com, william.gray@...aro.org
Subject: Re: [PATCH v3 5/5] arm64: mte: add compression support to mteswap.c
On Tue, Jul 18, 2023 at 12:48:00PM +0200, Alexander Potapenko wrote:
...
> > > +void _mte_free_saved_tags(void *storage)
> > > +{
> > > + unsigned long handle = xa_to_value(storage);
> > > + int size;
> > > +
> > > + if (!handle)
> > > + return;
> >
> > Perhaps
> >
> > unsigned long handle;
> >
> > handle = xa_to_value(storage);
> > if (!handle)
> > return;
>
> I don't have a strong preference and am happy to change this, but, out
> of curiosity, why do you think it is better?
> This pattern (calling (even non-)trivial functions when declaring
> variables) is widely used across the kernel.
> Or is it just for consistency with how `handle` is used in the rest of the file?
Ah, it's pure maintenance and error prone approach in case some code is sneezed
in between.
Imagine that you have
foo = bar(x);
...many lines that by some reason don't make one page on the screen...
if (!foo)
...do something...
Now if by unsuccessful rebase or by non-experienced developer we got
foo = bar(x);
...part 1 of many lines that by some reason don't make one page on the screen...
baz(foo);
...part 2 of many lines that by some reason don't make one page on the screen...
if (!foo)
...do something...
the compiler will eliminate the check — you got your mine on the nice minefield!
> > > +}
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists