public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: hjstein@bfr.co.il (Harvey J. Stein)
To: "Brad M. Garcia" <bgarcia@fore.com>
Cc: hjstein@bfr.co.il
Subject: Re: suggest parentheses around assignment used as truth value
Date: Thu, 02 Jul 1998 01:39:00 -0000	[thread overview]
Message-ID: <m2hg108x5s.fsf@blinky.bfr.co.il> (raw)
In-Reply-To: <Pine.LNX.3.96.980701065342.1337A-100000@spud.eng.fore.com>

"Brad M. Garcia" <bgarcia@fore.com> writes:

 > > I'd just like to register my opiniont that code like
 > > 
 > > if (x = p()) {...}
 > > 
 > > shouldn't generate a warning under gcc -Wall.  Even if
 > > you feel that code like this is obscure, the recommended
 > > 
 > > if ((x = p())) {...}
 > > 
 > > is just bizarre.
 > 
 > In 80% (don't you love making up statistics?) of cases where "=" is
 > used inside an "if" expression, the programmer meant to use "==".  So
 > the warning is helpful.

I believe the original poster might be making a distinction btw

   if (x = p()) ...

and

   if (x = y) ...

The second case (where the lvalue and rvalue are variables) is the one
where comparison is typically meant instead of assignment, and which
the gcc warning should apply to.

In the first case (where the rvalue is a function call) it's not at
all clear to me that comparison

   if (x == p()) ...

is more common than assignment

   if (x = p()) ...

or even that assignment is a common mistake when the programmer means
comparison.

There are bad things about both constructs.  The first is doing a
comparision inside the if test instead of an assignment, but is also
losing the return value of the function.  The second is keeping the
return value, which is a good thing, but at the cost of doing an
assignment inside of the if test.

It's not clear that gcc should value one over the other.

Maybe there should be a different independently settable warning for
the case where the rvalue is a function return?

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il

  parent reply	other threads:[~1998-07-02  1:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-01  4:00 Brad M. Garcia
1998-07-01 20:20 ` Tim Hollebeek
1998-07-02  1:39 ` Harvey J. Stein [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-06-30 19:49 Marc Rouaix
1998-07-01  2:51 ` Andreas Schwab
1998-07-01  9:20   ` Richard Earnshaw
1998-07-01 21:20     ` Bill Currie
1998-07-02  7:08       ` Richard Earnshaw
1998-07-03  3:31         ` Nathan Sidwell
1998-07-03  6:15           ` Richard Earnshaw
1998-07-01  3:42 ` Branko Cibej
1998-07-02  7:08 ` Carlo Wood
1998-07-03 14:48   ` Kamil Iskra

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=m2hg108x5s.fsf@blinky.bfr.co.il \
    --to=hjstein@bfr.co.il \
    --cc=bgarcia@fore.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).