[Bug c/97370] comedy of boolean errors for '!a & (b|c)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370 Paul Eggert changed: What|Removed |Added CC||eggert at gnu dot org --- Comment #4 from Paul Eggert --- (In reply to Harald van Dijk from comment #3) > Perhaps the warning could be suppressed specifically for boolean variables, > since those make it more likely that the (!a) & b meaning is exactly what is > intended? Yes, that's the idea. When a and b are booleans, !a & b has just one sensible interpretation, and people are no more likely to get it wrong than to get -a + b wrong. This distinguishes this case from the one discussed in PR 7543.
[Bug c/97370] comedy of boolean errors for '!a & (b|c)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370 --- Comment #3 from Harald van Dijk --- (In reply to eggert from comment #2) > That's so unlikely as to not be worth worrying about. See PR 7543 for the history of that warning. > And even if it were > more likely, the same argument would apply to !a && b. A very significant difference is that !a && b is commonly seen where it is exactly what the programmer wanted. For !a & b, that is not generally the case. Perhaps the warning could be suppressed specifically for boolean variables, since those make it more likely that the (!a) & b meaning is exactly what is intended? > The GCC documentation says the motivation for warning about ~bool is that > it's very likely a bug in the program. This motivation does not apply to > bool & ~bool, so it'd be better to not warn for that case. Agreed. Apologies for the confusion there, I was trying to say I think the suggestion to use ~ should be dropped, in which case the warning generated for the ~ form becomes unrelated to your issue. I was not trying to say that the warning generated for the ~ form should be kept.
[Bug c/97370] comedy of boolean errors for '!a & (b|c)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370 --- Comment #2 from eggert at cs dot ucla.edu --- (In reply to Harald van Dijk from comment #1) > When an expression is written as !a & b, it is possible the user intended > !(a & b). That's so unlikely as to not be worth worrying about. And even if it were more likely, the same argument would apply to !a && b. Surely you're not suggesting -Wparentheses should diagnose !a && b (that would generate many false alarms), so -Wparentheses shouldn't diagnose !a & b either. > You're correct that bool & ~bool will have > the intended result but my opinion is that that is overly clever code that > hurts readability, and GCC should not be offering that as a suggestion. The GCC documentation says the motivation for warning about ~bool is that it's very likely a bug in the program. This motivation does not apply to bool & ~bool, so it'd be better to not warn for that case. -Wbool-operation is intended to diagnose likely bugs, not to diagnose "bad" style.
[Bug c/97370] comedy of boolean errors for '!a & (b|c)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #1 from Harald van Dijk ---
> * 'f' is incorrectly diagnosed even though it's the same thing as 'i' after
> commuting the operands of '&'. ('i' is correctly allowed.)
When an expression is written as !a & b, it is possible the user intended !(a &
b). If it is rewritten as b & !a, it is clear that the user did not intend !(b
& a).
> * The diagnostic for 'f' suggests 'g', but 'g' produces the same diagnostic.
Indeed, and that looks like a bad suggestion by GCC to me. The diagnostic for
'f' should be suggesting (!a) rather than !(a), which does manage to suppress
the diagnostic.
> * The diagnostic for 'f' sugggests 'h', but 'h' produces a different
diagnostic.
Although in general, informing the user that they may have wanted to use ~ may
be useful, I personally think that suggestion should be dropped if the operand
is of type _Bool/bool. You're correct that bool & ~bool will have the intended
result but my opinion is that that is overly clever code that hurts
readability, and GCC should not be offering that as a suggestion.
