This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add a warning for suspicious use of conditional expressions in boolean context
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Joseph Myers <joseph at codesourcery dot com>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 12 Sep 2016 13:30:26 -0600
- Subject: Re: [PATCH] Add a warning for suspicious use of conditional expressions in boolean context
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB21624AB3DECA1269E4BBB475E4E50@AM4PR0701MB2162.eurprd07.prod.outlook.com>
On 09/02/2016 12:53 PM, Bernd Edlinger wrote:
Hi!
As reported in PR77434 and PR77421 there should be a warning for
suspicious uses of conditional expressions with non-boolean arguments.
This warning triggers on conditional expressions in boolean context,
when both possible results are non-zero integer constants, so that
the resulting truth value does in fact not depend on the condition
itself. Thus something like "if (a == b ? 1 : 2)" is always bogus,
and was most likely meant to be "if (a == (b ? 1 : 2))".
Boot-strap and reg-testing on x86_64-pc-linux-gnu without regressions.
Is it OK for trunk.
Thanks
Bernd.
changelog-pr77434.txt
gcc:
2016-09-02 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR c++/77434
* doc/invoke.texi: Document -Wcond-in-bool-context.
PR middle-end/77421
* dwarf2out.c (output_loc_operands): Fix assertion.
c-family:
2016-09-02 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR c++/77434
* c.opt (Wcond-in-bool-context): New warning.
* c-common.c (c_common_truthvalue_conversion): Warn on integer
constants in boolean context.
testsuite:
2016-09-02 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR c++/77434
* c-c++-common/Wcond-in-bool-context.c: New test.
For some reason the non-symmerty of the changes to
c_common_truthvalue_conversion caused me to have to think far more about
this than I probably should have.
Couldn't we have a new function
integer_zerop_or_onep
Then use
&& (!integer_zerop_or_onep (TREE_OPERAND (expr, 1))
|| !integer_zerop_or_onep (TREE_OPERAND (expr, 2)))
Ie, if they're both constants and either is not [0,1], then we warn.
With that cleanup, this is OK.
jeff