From: "James K. Lowden" <jklowden@freetds.org>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc@gnu.org
Subject: Re: -Wparentheses lumps too much together
Date: Thu, 20 Dec 2007 06:08:00 -0000 [thread overview]
Message-ID: <20071220005030.4971a442.jklowden@freetds.org> (raw)
In-Reply-To: <m3hciewav7.fsf@localhost.localdomain>
Ian Lance Taylor wrote:
> I have no objection to splitting -Wparentheses into separate warnings
> controlled by separate options.
Thank you, Ian.
> > which yields (as you know) advice to parenthesize the two && pairs.
>
> That particular warning happened to find dozens of real errors when I
> ran it over a large code base. It may be noise for you, but I know
> from personal experience that it is very useful.
I would like to hear more about that, if you wouldn't mind. I'm really
quite surprised. Honestly.
I don't claim to be the last arbiter in good taste. It sounds like you're
saying that this warning, when applied to code of uncertain quality,
turned up errors -- cases when the code didn't reflect (what must have
been) the programmer's intentions. My untested (and consequently firmly
held) hypothesis is that
1) most combinations of && and || don't need parentheses because
(a && b) || (c && d)
is by far more common than
a && (b || c) && d
and, moreover, broken code fails at runtime, and
2) Most programmers know (because they need to know) that && comes before
||.
I'm sure a few years spent working with the GCC and fielding questions
about it would lower my opinion of the average programmer, so I won't try
to convince you. But I would like to know more about what you found,
because that's at least objective evidence. I was unable to find any
metrics supporting the inclusion of this particular warning in -Wall.
I would hold to this, though: the warnings about precedence are of a
different order than warnings about nesting. I suggest that well vetted
code doesn't benefit from the kind of false positives that -Wparentheses
can generate.
I very much appreciate your time and effort.
Kind regards,
--jkl
next prev parent reply other threads:[~2007-12-20 5:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 20:07 jklowden
2007-12-19 20:14 ` Doug Gregor
2007-12-19 20:39 ` Ismail Dönmez
2007-12-19 20:15 ` Daniel Jacobowitz
2007-12-19 23:11 ` Ian Lance Taylor
2007-12-20 6:08 ` James K. Lowden [this message]
2007-12-20 16:41 ` Paul Brook
2007-12-21 20:19 ` Ross Smith
2008-01-11 7:34 ` Rehno Lindeque
2008-01-11 17:00 ` Joe Buck
2008-01-11 17:05 ` Robert Dewar
2008-01-11 23:26 ` Ian Lance Taylor
2008-01-12 0:50 ` Joe Buck
2007-12-20 18:01 ` Ian Lance Taylor
2007-12-21 5:28 ` James K. Lowden
2007-12-21 9:27 ` Ralf Wildenhues
2007-12-21 17:16 ` NightStrike
2008-01-11 22:44 ` Doug Gregor
2008-01-12 3:48 ` Ian Lance Taylor
2008-01-12 10:16 ` Andreas Schwab
2008-01-12 11:23 ` Paolo Bonzini
2008-01-13 16:03 ` Gabriel Dos Reis
2008-03-10 17:25 Derek M Jones
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=20071220005030.4971a442.jklowden@freetds.org \
--to=jklowden@freetds.org \
--cc=gcc@gnu.org \
--cc=iant@google.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).