lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ba15ff7a-8766-43db-be7c-f971bf6dc8d6@kili.mountain>
Date:   Wed, 15 Mar 2023 07:19:47 +0300
From:   Dan Carpenter <error27@...il.com>
To:     Alison Schofield <alison.schofield@...el.com>
Cc:     Julia Lawall <julia.lawall@...ia.fr>,
        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 Tue, Mar 14, 2023 at 05:25:06PM -0700, Alison Schofield wrote:
> 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 ;)
> 

I think you wanted to CC Joe, not me?

I agree with Julia, but I also have slightly kind of given up resisting
on this one when people start adding unnecesary parentheses.

Fixing the COMPLEX_MACRO macro warning to ignore cast operations would
be a great idea for a small project.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ