public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order
@ 2007-06-10 8:16 bugzilla at little-bat dot de
2007-06-10 8:34 ` [Bug c++/32270] " pinskia at gcc dot gnu dot org
2007-06-10 8:39 ` pinskia at gcc dot gnu dot org
0 siblings, 2 replies; 3+ messages in thread
From: bugzilla at little-bat dot de @ 2007-06-10 8:16 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/32270] warning for potential undesired operator& and operator== evaluation order
2007-06-10 8:16 [Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order bugzilla at little-bat dot de
@ 2007-06-10 8:34 ` pinskia at gcc dot gnu dot org
2007-06-10 8:39 ` pinskia at gcc dot gnu dot org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-10 8:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/32270] warning for potential undesired operator& and operator== evaluation order
2007-06-10 8:16 [Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order bugzilla at little-bat dot de
2007-06-10 8:34 ` [Bug c++/32270] " pinskia at gcc dot gnu dot org
@ 2007-06-10 8:39 ` pinskia at gcc dot gnu dot org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-10 8:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-06-10 8:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-10 8:16 [Bug c++/32270] New: warning for potential undesired operator& and operator== evaluation order bugzilla at little-bat dot de
2007-06-10 8:34 ` [Bug c++/32270] " pinskia at gcc dot gnu dot org
2007-06-10 8:39 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).