[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBEQYp/z+C/JeR98@aschofie-mobl2>
Date: Tue, 14 Mar 2023 17:25:06 -0700
From: Alison Schofield <alison.schofield@...el.com>
To: Julia Lawall <julia.lawall@...ia.fr>,
Dan Carpenter <error27@...il.com>
Cc: Menna Mahmoud <eng.mennamahmoud.mm@...il.com>,
outreachy@...ts.linux.dev, lars@...afoo.de,
Michael.Hennerich@...log.com, jic23@...nel.org,
gregkh@...uxfoundation.org, linux-iio@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: iio: meter: enclose Macros with complex values
in parentheses
On Sun, Mar 12, 2023 at 03:25:37PM +0100, Julia Lawall wrote:
>
>
> On Sun, 12 Mar 2023, Menna Mahmoud wrote:
>
> >
> > On ١٢/٣/٢٠٢٣ ١٦:١٢, Julia Lawall wrote:
> > >
> > > On Sun, 12 Mar 2023, Menna Mahmoud wrote:
> > >
> > > > enclose Macros with complex values in parentheses is especially useful
> > > > in making macro definitions “safe” (so that they
> > > > evaluate each operand exactly once).
> > > enclose -> Enclose, and Macros -> macros
> > >
> > > I don't understand the above comment though. How does adding parentheses
> > > around the body of a macro cause the operands to be evaluated only once?
> > > And the macros that you have changed don't have any operands.
> > >
> > > The value of adding parentheses is normally to ensure that the body of the
> > > macro doesn't interact with the context in a weird way. For example, you
> > > could have
> > >
> > > #define ADD 3 + 4
> > >
> > > Then if you use your macro as 6 * ADD, you will end up evaluating
> > > 6 * 3 + 4, ie 18 + 4, when you might have expected 6 * 7. The issue is
> > > that * has higher precedence than +.
> >
> >
> > yes, I mean that but i couldn't explain it well, thanks for your feedback.
> >
> >
> > >
> > > But I don't think that such a problem can arise with a cast expression, so
> > > parentheses around it should not be necessary.
> >
> >
> > So, no need for this patch?
>
> No, I don't think so.
>
> julia
Looping in Dan C explicitly.
Can we revisit this one? It actually leads to a checkpatch ERROR.
So, anyone hoping to get an error free checkpatch run on this file,
is out of luck.
Is this something that checkpatch can learn about and allow, or
should we add the parens here, to dare I say, appease the checkpatch
god ;)
Alison
>
> >
> >
> > > > this error reported by chechpatch.pl
> > > this error is reported by checkpatch.
> > >
> > > > "ERROR: Macros with complex values should be enclosed in parentheses"
> > > >
> > > > for ADE7854_SPI_SLOW, ADE7854_SPI_BURST and ADE7854_SPI_FAST
> > > > macros and this error fixed by enclose these macros in parentheses.
> > > The last two lines aren't needed. One can easily see that from looking at
> > > the patch.
> >
> >
> > Got it, Thank you.
> >
> > Menna
> >
> > > julia
> > >
> > > > Signed-off-by: Menna Mahmoud <eng.mennamahmoud.mm@...il.com>
> > > > ---
> > > > drivers/staging/iio/meter/ade7854.h | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/iio/meter/ade7854.h
> > > > b/drivers/staging/iio/meter/ade7854.h
> > > > index 7a49f8f1016f..41eeedef569b 100644
> > > > --- a/drivers/staging/iio/meter/ade7854.h
> > > > +++ b/drivers/staging/iio/meter/ade7854.h
> > > > @@ -139,9 +139,9 @@
> > > > #define ADE7854_MAX_RX 7
> > > > #define ADE7854_STARTUP_DELAY 1000
> > > >
> > > > -#define ADE7854_SPI_SLOW (u32)(300 * 1000)
> > > > -#define ADE7854_SPI_BURST (u32)(1000 * 1000)
> > > > -#define ADE7854_SPI_FAST (u32)(2000 * 1000)
> > > > +#define ADE7854_SPI_SLOW ((u32)(300 * 1000))
> > > > +#define ADE7854_SPI_BURST ((u32)(1000 * 1000))
> > > > +#define ADE7854_SPI_FAST ((u32)(2000 * 1000))
> > > >
> > > > /**
> > > > * struct ade7854_state - device instance specific data
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
> >
Powered by blists - more mailing lists