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 / 10^9; tp->tv_nsec=attributes % 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)
2019-06-14 11:06:05 UTC
read_bytes(&f, (char *) &(val), ( (n
2019-06-14 11:33:04 UTC
But there's nothing invalid about these constant expressions? But yeah....
2019-06-14 11:33:46 UTC
Maybe we should accept 2**32 as extension ;)
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.
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).
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...
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.
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
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.
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.