[cfe-dev] [PATCH] -Wconversion-null

David Blaikie dblaikie at gmail.com
Thu Mar 15 18:55:45 PDT 2012


On Thu, Mar 15, 2012 at 6:31 PM, James K. Lowden
<jklowden at schemamania.org> wrote:
> On Thu, 15 Mar 2012 12:32:30 +0100
> Lubos Lunak <l.lunak at suse.cz> wrote:
>
>> On Thursday 15 of March 2012, James K. Lowden wrote:
>> > No, I can't agree.  The purpose of a warning is to indicate when a
>> > particular operation or construction might be unsafe.  A warning
>> > about something that cannot possibly be an error (as far as the
>> > machine is concerned) is just noise.
>>
>> Clang has a lot of noise then. Just one random example:
>>
>> $clang++ a.cpp
>> a.cpp:6:16: warning: '&&' within '||' [-Wlogical-op-parentheses]
>>     if( a == 1 && b == 2 || c == 3 )
>>         ~~~~~~~^~~~~~~~~ ~~
>> a.cpp:6:16: note: place parentheses around the '&&' expression to
>> silence this warning
>>     if( a == 1 && b == 2 || c == 3 )
>>                ^
>>         (               )
>> 1 warning generated.
>
>        "Saying a true thing twice doesn't make it truer."
>
> Babysitting good code is really, really easy. It also distracts from
> harder and more important work, never mind those of us who want to
> use it as a *tool*, not an instructional video.

You're welcome to disable the warnings - if that's your philosophy
you'll probably want to disable everything & then opt-in to warnings
that meet your bar.

> And it's not good for the community.

That's not so clear to me.

> I you squint really hard at the gcc archives, you'll find my name
> raising an objection to including that warning in -Wall, which many
> projects use as the "gold standard".

Personally I find the original assignment -Wparentheses warning a bit
curious - certainly once it was adopted as a common convention it
seems like a useful construct to make the intent more obvious (to both
other developers and the compiler) it's helpful, but it is a fairly
arbitrary convention.

The bool parentheses warning is a bit different - not so much an
arbitrary convention, but just a recommendation to make the precedence
more clear.

> Why do people think Boolean operations are hard?

Hard enough, apparently.

> Why don't they get their knickers in a twist over !, too?

You seem to be misunderstanding the approach here. Rather than "people
complain about not understanding a language feature" => "compiler
engineers implement a warning for that feature" it's really more like
"people keep making the same mistakes that cost companies real money
to fix those bugs" => "companies invest in tools that save them money
by avoiding that class of bugs".

>  When I looked into it
> back then, I could find only two kinds of languages: those that define
> logical precedence and those that don't.  Of those that do, all bind AND
> before OR.
>
> The code above is absolutely clear. If you don't know && comes
> before ||, and has for the last 25 years, learn!

It's not a matter of learning. People know this but when writing a lot
of code they eventually make mistakes. Even the best of us make these
mistakes - only a couple of days ago, see r152551 and r152559. I
really doubt I would've caught that on code review if it weren't for
the build break it caused.

> That's the real poverty of that warning:  instead of allowing clear
> code that uses the language correctly to instruct the less
> knowledgeable, it discourages such code and such learning.

If you think it's cheaper to educate people than provide the compiler
warning (& incur the cost of developers writing all those extra
parentheses (or using NULL rather than 0)) then perhaps you can profit
by selling people such education & saving them money.

Another point that crosses my mind: your approach seems to imply that
any language feature that made it to standardization is "right" & any
use of it in any form is no more or less of a good idea. The standards
committee/process really isn't that infallible.

- David




More information about the cfe-dev mailing list