Comment 1


Jonathan Wakely



2019-06-14 08:18:48 UTC

And maybe also 10^X where X is a literal.
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search

A sample:

        tp->tv_sec =attributes[0] / 10^9;
        tp->tv_nsec=attributes[0] % 10^9;
    
     range->pmin[TREND_FCT]=-10^10;
     range->pmax[TREND_MEAN]=10^10;


    #define IRQ_CHINT5_LEVEL        (12 ^ 7)
    #define IRQ_CHINT4_LEVEL        (11 ^ 7)
    #define IRQ_CHINT3_LEVEL        (10 ^ 7)
    #define IRQ_CHINT2_LEVEL        (9 ^ 7)
    #define IRQ_CHINT1_LEVEL        (8 ^ 7)


Comment 3


Jonathan Wakely



2019-06-14 11:06:05 UTC

	read_bytes(&f, (char *) &(val),
		   ( (n
   


Comment 4


Richard Biener



2019-06-14 11:33:04 UTC

But there's nothing invalid about these constant expressions?  But yeah....


Comment 5


Richard Biener



2019-06-14 11:33:46 UTC

Maybe we should accept 2**32 as extension ;)


Comment 6


Jonathan Wakely



2019-06-14 11:36:10 UTC

There's nothing wrong about implicit fallthrough, misleading indentation, ambiguous else, or missing parentheses in nested logic expressions either. But people get it wrong all the time.

I can't see a good reason to write 2^16 when you mean 18, or 10^9 when you mean 3, so it's probably a bug. And there's an easy workaround to avoid the warning: just write the exact constant as a literal, not an XOR expression.


Comment 8


Jonathan Wakely



2019-06-14 11:48:53 UTC

The right heuristic for the warning isn't entirely obvious though.

I think it should only warn when both operands are integer literals. Should all kinds of integer literals be treated equally? Is 0x11 ^ 0b0011 wrong? Maybe not as obviously as 2^8 and 2^32.

Do these mistakes only happen for powers of 2 and powers of 10? Is it worth warning about 3^4?

After some more searches I'm not even sure 10^ is common enough to worry about. Maybe it should only warn for 2 ^ integer-literal.

Warning X^X where the same literal is given twice probably makes sense, that would catch the 10^10 case incomment 1(but not the -10^10 one).


Comment 9


Eric Gallager



2019-06-14 17:06:18 UTC

Confirmed. More discussion from that thread about possible heuristics for the warning:https://twitter.com/elwoz/status/1139522678396784642
* restricting it to just decimal literals probably makes sense, if someone is using the 0x or 0b prefix, they probably are in fact intending to do bit-twiddling with xor
* the "not from the expansion of’s xor macro" criterion I can see possibly being a difficulty, due to how many other bugs there are about gcc's handling of macros from system headers...


Comment 10


Jonathan Wakely



2019-06-14 17:33:16 UTC

(In reply to Eric Gallager fromcomment #9)
>* the "not from the expansion of’s xor macro" criterion I can see
>possibly being a difficulty, due to how many other bugs there are about
>gcc's handling of macros from system headers...

That's not relevant to C++ because xor is a keyword not a macro.


Comment 11


David Malcolm



2019-06-14 17:35:28 UTC

Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree withcomment #6).

Not sure what to call it: "-Wexclusive-or"???

I think we'd want to *not* warn if either of the operands are from a macro expansion.

I think both operands ought to be decimal integers to trigger the warning.

I like the wording fromcomment #2: "2 ^ 30 is 28, not 1073741824.", to make it clear what's going on (I hope).

Other idea: fix-it hints.

So maybe something like:

t.c:10:5: warning: '2^30' is 28; did you mean '1
   


Comment 12


Jonathan Wakely



2019-06-14 17:42:07 UTC

(In reply to David Malcolm fromcomment #11)
>Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
>withcomment #6).
>
>Not sure what to call it: "-Wexclusive-or"???

I suppose -Wxor is a bit cryptic-lookin'

What about -Wxor-used-as-pow ?

>I think we'd want to *not* warn if either of the operands are from a macro
>expansion.
>
>I think both operands ought to be decimal integers to trigger the warning.

And not warn if the C++ 'xor' keyword is used, as nobody's going to think that "2 xor 8" means raising to the 8th power.

>I like the wording fromcomment #2: "2 ^ 30 is 28, not 1073741824.", to make
>it clear what's going on (I hope).

Yes, that's also how I phrased the various pull requests and bug reports I've submitted today.


Comment 13


Zack Weinberg



2019-06-15 02:30:17 UTC

Since examples of this error were observed with base 10, I think the warning should cover 10^i for decimal literal i, too.

Relatedly, “note: ^ performs exclusive or, not exponentiation” might be a nice addition to the existing error for ^ with a float for either operand.


Comment 14


Richard Biener



2019-06-17 08:57:11 UTC

(In reply to David Malcolm fromcomment #11)
>Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
>withcomment #6).
>
>Not sure what to call it: "-Wexclusive-or"???

-Wexp[onential] or -Wpow[er]?

Read More

LEAVE A REPLY

Please enter your comment!
Please enter your name here