Re: /bzr/squid3/trunk/ r12903: Instruct clang not to treat unused command line arguments as errors

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 11 Jun 2013 02:07:50 +1200

On 11/06/2013 12:59 a.m., Kinkie wrote:
> On Mon, Jun 10, 2013 at 11:27 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 10/06/2013 8:35 a.m., Francesco Chemolli wrote:
>>> ------------------------------------------------------------
>>> revno: 12903
>>> committer: Francesco Chemolli <kinkie_at_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
Received on Mon Jun 10 2013 - 14:08:06 MDT

This archive was generated by hypermail 2.2.0 : Mon Jun 10 2013 - 12:00:22 MDT