On 11/06/2013 12:59 a.m., Kinkie wrote:
On Mon, Jun 10, 2013 at 11:27 AM, Amos Jeffries <squ...@treenet.co.nz> wrote:
On 10/06/2013 8:35 a.m., Francesco Chemolli wrote:
------------------------------------------------------------
revno: 12903
committer: Francesco Chemolli <kin...@squid-cache.org>
branch nick: trunk
timestamp: Sun 2013-06-09 22:35:58 +0200
message:
Instruct clang not to treat unused command line arguments as errors
modified:
acinclude/compiler-flags.m4
Anyone known why we have the "-Wno-error=parentheses-equality" option in teh
first place?
It would seem to me to be one of the warnings highlighting a coding
guideline violation we need to fix in the sources. Not something to be
suppressed.
I do, as I added it:
in case of
if (bool foo = somefunction()) {
}
gcc -Werror barfs unless it's expressed as:
if ((bool foo = somefunction())) {
}
while clang -Werror barfs for the unneeded parentheses, at least for
some clang versions
That option makes clang accept the GCC-ism.
The portable solution would probably be a macro:
stuff like:
if (MAYBE_PARENTHESIZE(bool foo = somefunction()) {
}
That'd be a readability FAIL.
Or auto-detect what clang version in use requires the option to compile
the test cases?
That would allow us to enable the checks as often as possible without
causing problems on specific clang.
Also, note that we have a minimum version of clang simpy to be able to
compile the stdc++11 features we use. Halting the build in ./configure
with a message to upgrade clang is a possibility.
The cases here are that assignment "if ((a=b))" requires parenthesis,
equality "if (a==b)" requires single parenthesis. Otherwise the compiler
generated code is not completely predictable. GCC and clang should both
complain only if the cases are mixed up, otherwise it is a bug in the
compiler.
Amos
