From owner-svn-src-all@FreeBSD.ORG Sun Oct 27 21:43:42 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 929B2686; Sun, 27 Oct 2013 21:43:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 21B702F27; Sun, 27 Oct 2013 21:43:41 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id F0F231A2748; Mon, 28 Oct 2013 08:43:38 +1100 (EST) Date: Mon, 28 Oct 2013 08:43:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: svn commit: r257203 - head/sys/arm/arm In-Reply-To: <1382900401.1170.227.camel@revolution.hippie.lan> Message-ID: <20131028081925.C2294@besplex.bde.org> References: <201310270329.r9R3Tcoi076809@svn.freebsd.org> <20131028040222.G929@besplex.bde.org> <1382900401.1170.227.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=zbkiI427TaUA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=E11o_6pwCccA:10 a=5rOP3BK-mveX7-Rzz9EA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 21:43:42 -0000 On Sun, 27 Oct 2013, Ian Lepore wrote: > On Mon, 2013-10-28 at 04:42 +1100, Bruce Evans wrote: >> On Sun, 27 Oct 2013, Ian Lepore wrote: >> >>> Log: >>> Eliminate a compiler warning about extraneous parens. >> >> Wow, what flags give these warnings? > > --- busdma_machdep.o --- > /local/build/staging/freebsd/dp10/src/sys/arm/arm/busdma_machdep.c:811:24: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] > if ((map->pagesneeded == 0)) { > ~~~~~~~~~~~~~~~~~^~~~ Ahh. I guess what I really want is -Wredundant-parentheses -Wredundant-braces ... The parser can easily tell what is redundant than what is bogus since bogusness depends on style and too many suboptions would be required to specify styles (-Wparentheses[-operator][-context]. Oops, the parser easily can't do this right because macro parameters must usually have redundant parentheses and C parsers are specified to act as if on the output of the preprocessor so they can't easily either have a special case to ignore these redundant parentheses or know that they aren't in the unpreprocessed source so they should be ignored. > /local/build/staging/freebsd/dp10/src/sys/arm/arm/busdma_machdep.c:811:24: note: remove extraneous parentheses around the comparison to silence this warning > if ((map->pagesneeded == 0)) { > ~ ^ ~ > /local/build/staging/freebsd/dp10/src/sys/arm/arm/busdma_machdep.c:811:24: note: use '=' to turn this equality comparison into an assignment > if ((map->pagesneeded == 0)) { > ^~ > = > > That's what the compiler had to say about it. I guess in somebody's > mind if it's a probable error to have done > ... This expression could be the result of a macro #define ISZERO(x) ((x) == 0) which for if (ISZERO(map->pagesneeded)) expands to almost the above. I guess clang warns excessively about this. > The warning doesn't bother me as much as the two useless notes that > follow it (which are annoying when combined with my editor's feature of > parsing compiler output and jumping to the next error point in the > code). I've notice clang is particularly chatty, with things like > suggesting what you might have meant when you spell a variable name > wrong. Before long it's going to be like RPG and COBOL where it's > willing to assume what you meant and try to generate runnable code in > the face of almost any error. The verbose prettyprinted output can be annoying. If clang would print its man page then I might know its options so I could turn it off :-). > I probably date myself with references to RPG and COBOL, but it does > bring back fond memories of slapping a boilerplate header on every > interoffice memo issued by management and running it through the cobol > compiler, and grading them on whether their memos generated runnable > code or so many errors the compiler gave up. I started late enough to not touch these or spend more than 2 years on accounting-related software. Bruce