From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12845 invoked by alias); 19 Dec 2007 20:03:33 -0000 Received: (qmail 12833 invoked by uid 22791); 19 Dec 2007 20:03:33 -0000 X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 20:03:26 +0000 Received: from mx10.gnu.org ([199.232.76.166]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J558W-0000Lo-Pm for gcc@gnu.org; Wed, 19 Dec 2007 15:03:24 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1J558V-0006IS-Lo for gcc@gnu.org; Wed, 19 Dec 2007 15:03:25 -0500 Received: from dsl254-083-208.nyc1.dsl.speakeasy.net ([216.254.83.208] helo=oak.schemamania.org) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J558V-0006BR-9l for gcc@gnu.org; Wed, 19 Dec 2007 15:03:23 -0500 Received: by oak.schemamania.org (Postfix, from userid 1000) id 4E27650D09; Wed, 19 Dec 2007 15:02:35 -0500 (EST) Date: Wed, 19 Dec 2007 20:07:00 -0000 From: jklowden@freetds.org To: gcc@gnu.org Subject: -Wparentheses lumps too much together Message-ID: <20071219200235.GA21525@oak.schemamania.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-detected-kernel: by monty-python.gnu.org: NetBSD 1.6Z or 2.0 (DF) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00592.txt.bz2 Hello Gentlemen, Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest to you that -Wparentheses should be split up, and things it checks/suggests be moved out of -Wall. If this is not the right forum or if you'd rather see this as a bug report, I'm happy to go where I'm pointed. The basic problem with this warning is that it includes some helpful advice about some subtle bugs with some "dear beginner" advice about "operators ... whose precedence people often get confused about." My assertion is that operator precedence is fundamental to C. No one can read C without knowing. If you're unsure about precedence, you're only guessing. Moreover, to interpret operator precedence, it's not necessary to, say, rememember the variables' declarations 100 lines earlier and it's impossible to be misled by non-syntactic indentation. Everything you need to know to understand the statement is contained in the statement itself. My specific candidate for exclusion from -Wall is this one: if (a && b || c && d) which yields (as you know) advice to parenthesize the two && pairs. I very much think this is unhelpful, counterproductive advice. Yes, I know beginners get confused by and/or precedence. But *every* language that I know of that has operator precedence places 'and' before 'or'. More important, a C programmer will encounter many thousands such expressions in his dealings with the language. To "help" him is merely to retard his education. But -Wall isn't really concerned with helping beginners, right? It's really about avoiding errors and pitfalls. That's why I suggest this and other precedence warnings be moved to -Woperator (notional). If you need help learning C, GCC will help you. But if you're maintaining 100,000 lines of portable, standards-compliant C (as I do), you don't want warnings to parenthesize things that don't need it. At the risk of overstaying my welcome, let me answer the commonest reply, "what's a few parentheses among friends?" The problem is that, for the experienced programmer, "extra" parenthesis are a signal: something unusual is going on here. By forcing your most careful users -- those who bother with -Wall -- to use parenthesis to enforce what the compiler would do anyway where the meaning was clear(er) without them, you're removing a signalling tool by "insisting" on white noise. I don't think that's a good outcome and I doubt it was the intention, but there it is. By the way, I distinguish the 'and/or' advice from the more helpful concern: while ((erc=foo()) != 0) because there the programmer's intent is likely impossible to express without parentheses; the idiom requires the override. One last point. In looking for the rationale behind this warning, I searched for examples of it. I didn't find any discussion on this list. What I did find were many examples of people rototilling perfectly fine code, "improving" it by adding unneeded parenthesis specifically so that it would compile cleanly with -Wall. I think that's a shame: a waste of effort at best. I ask you, please, to consider splitting advice about operator precedence from advice about mismatched if/else branches, and to exclude advice about making sure && is parenthesized ahead of || from -Wall. -Wall is the standard for "good, clean code" in many projects. This warning doesn't belong there. Thank you for your time and consideration. Regards, --jkl