All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Sumitra Sharma <sumitraartsy@gmail.com>, Ira Weiny <ira.weiny@intel.com>
Cc: Julia Lawall <julia.lawall@inria.fr>, <outreachy@lists.linux.dev>
Subject: Re: Warn on macros with flow control statements
Date: Thu, 23 Mar 2023 09:19:11 -0700	[thread overview]
Message-ID: <641c7bffa237c_3030592941f@iweiny-mobl.notmuch> (raw)
In-Reply-To: <20230323062853.GB155612@sumitra.com>

Sumitra Sharma wrote:
> On Fri, Mar 17, 2023 at 11:19:12PM -0700, Ira Weiny wrote:
> > Julia Lawall wrote:
> > > > Based on the flow control I would do something like this.  It is a bit more
> > > > verbose but is very clear what is happening.
> > > >
> > > 
> > > Ira, what do you think of my suggestion of
> > > 
> > > err = err || qlge_fill_seg_(...);
> > > 
> > > It would avoid 40 lines of ifs, and would still avoid calling
> > > qlge_fill_seg_ as soon as there is a failure.  On ther other hand, I don't
> > > recall this being done elsewhere, so maybe all the ifs would be
> > > preferable.
> > 
> > Oh sorry.  I miss read your suggestion and I thought it was going to
> > continue running qlge_fill_seg_() for all the other calls.  I read this
> > as:
> > 
> > err = err | qlge_fill_seg_(...);
> > 
> > Not sure why.  Just late I guess.
> > 
> > Yes your suggestion would work.  I do think it is a bit odd though.
> >
> 
> Hi Ira,
> 
> I would like to know why do you think this is odd? 

First, it is _not_ wrong.  Just was odd in my head.

> 
> PS: I was trying to implement your suggestion and was able to connect to
> what julia wrote here. 
> 
> For reference this is the link to your suggestion https://lore.kernel.org/outreachy/64154d438f0c8_28ae5229421@iweiny-mobl.notmuch/

I think what Julia proposes is better given this is a pattern is used
elsewhere.  I've just not run across it myself.

I find it odd because the parser in my head is not used to it.  :-D  But
sometimes one has to _read_ the code carefully.  ;-)

Again, I think Julia's suggestion is best given that mine will result in a
lot more code in the end.  And when reading the function you really only
have to grok the first call.  Then the pattern holds through the function.

Ira

      parent reply	other threads:[~2023-03-23 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16  8:08 Warn on macros with flow control statements Sumitra Sharma
2023-03-16  8:26 ` Julia Lawall
2023-03-17  7:23   ` Sumitra Sharma
2023-03-18  5:33 ` Ira Weiny
2023-03-18  6:05   ` Julia Lawall
2023-03-18  6:19     ` Ira Weiny
2023-03-23  6:28       ` Sumitra Sharma
2023-03-23  8:15         ` Julia Lawall
2023-03-23 16:25           ` Ira Weiny
2023-03-23 16:19         ` Ira Weiny [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=641c7bffa237c_3030592941f@iweiny-mobl.notmuch \
    --to=ira.weiny@intel.com \
    --cc=julia.lawall@inria.fr \
    --cc=outreachy@lists.linux.dev \
    --cc=sumitraartsy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.