[Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order

[Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order

[bugzilla at little-bat dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Hello,

i don't know whether this was already requested way back in 1985, and maybe
there is an evangelical answer to this. 

This is a request to add a compiler option for warnings if the evaluation of
operator& and operator== (and similar) may be not 'as expected'. I personally
feel it in most cases utter nonsens to apply operator& on a boolean result, as
it is defined in the C/C++ operator precedence hierarchy; and every now and
then i forget to add brackets around each and every operation in doubt in an
expression and then i'm puzzled for hours what goes wrong.

Example:

  if( value&mask == $7F00 ) { … }

does not evaluate as expected and, in my opionion, the only reasonable way, but
evaluates as:

  if( value & (mask==$7F00) ) { … }

The reasoning for adding this warning is comparable to the reasoning which lead
to add a warning if the result of operator= is used as part of the boolean
expression in "if(…){…}": It is _probably_ not what the programmer intended.
The way to circumvent the warning (if enabled) would be the same as for
operator= too: add brackets around the expression. Eventually these warnings
could even be combined into a single compiler option, but they probably should
go into the same compiler option sets.

Exact scope for this kind of warning should be:

  operator &, ^ and |   versus   operator == and !=

because it makes no sense to apply a bit masking operator on a boolean result,
as it is done if no brackets are used to reorder the sequence of evaluation.

And the same applies in my eyes to:

  operator << and >>   versus   operator +, -, *, / and %

because operator<< and >> do an exponentation 2**n and the priority of
exponentation is (should be) higher than that of multiplication.

The C/C++ standard cannot be changed, though it handles it wrong in my opinion,
but adding a warning if the default evaluation order is applied to 2 operations
from the above sets would be very appreciated in my eyes.

Thanks for an answer,

    ... kio !


-- 
           Summary: warning for potential undesired operator& and operator==
                    evaluation order
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bugzilla at little-bat dot de
 GCC build triplet: (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
  GCC host triplet: powerpc-apple-darwin8-g++-4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32270

[Bug c++/32270] warning for potential undesired operator& and operator== evaluation order

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-10 08:34 -------
The warning works on the trunk:
[pinskia-laptop:gcc/mips/gcc] pinskia% ./cc1plus t.c -W -Wall
 int f(int, int)
t.c:3: warning: suggest parentheses around comparison in operand of &


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|(GCC) 4.0.1 (Apple Computer,|
                   |Inc. build 5367)            |
   GCC host triplet|powerpc-apple-darwin8-g++-  |
                   |4.0.1                       |
           Keywords|                            |diagnostic
            Summary|warning for potential       |warning for potential
                   |undesired operator& and     |undesired operator& and
                   |operator== evaluation order |operator== evaluation order
            Version|4.3.0                       |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32270

[Bug c++/32270] warning for potential undesired operator& and operator== evaluation order

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-10 08:38 -------
Well that is because it was fixed on the trunk last December by:
2006-12-13  Ian Lance Taylor  <iant@google.com>

        PR c++/19564
        PR c++/19756

This is a dup of bug 19564.

*** This bug has been marked as a duplicate of 19564 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32270