4 ms·

It's a warning not an error. Moreover, it is very hard to come up with a legitimate usecase of 2^32 as an expression. People who use it to set bit flags will us

• NotPaidToPost 7y ago
  > It's a warning not an error. Many build environments are set to treat all warnings as errors. The point is that 2^32 is a perfectly compliant C expression that is neither misleading nor ambiguous, and that also won't create any variable overflow. It uses ^ exactly as intended. Why should the compiler complain? Why should I get a warning/error when following the spec to the letter?
  • lifthrasiir 7y ago
    Like it or not, there are already tons of lint-like warnings in GCC [1] and clang [2]. Many (uh, most?) of them are not required by the C/C++ standards (which by the way have their own requirements for diagnostic messages). [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [2] https://clang.llvm.org/docs/DiagnosticsReference.html https://clang.llvm.org/docs/DiagnosticsReference.html
  • stestagg 7y ago
    Environments where the decision has been made that error-prone, misleading and ambiguous statements should not be allowed typically are those where warning are treated as errors. A new type of misleading and error-prone statement has been found, so it seems entirely reasonable that this is added to that list. This seems to be the entire intent of compiler warnings (these days anyway)
  • pjc50 7y ago
    The compiler should complain because it's overwhelmingly likely to be a mistake.
  • barrkel 7y ago
    Plenty of valid expressions generate warnings. A frequent gotcha is `=` in boolean contexts. Warnings are justified, and can normally be avoided with a little bit more lexical work (e.g. an extra set of parentheses). The upside is large and the downside is miniscule.
    • OskarS 7y ago
      Isn't that pretty much the definition of a warning? An expression that is technically valid, but probably a mistake. If something wasn't a valid expression, it would be a compiler error, not a warning.
      • mikeash 7y ago
        Usually, yes. C is weird because undefined behavior is illegal, can sometimes be detected statically, and yet will not produce an error. So sometimes you get warnings for invalid yet error-free code. It’s a strange language.
  • viraptor 7y ago
    You can turn specific warnings off. You can also usually disable them inline. There are very common ways to deal with false positive warnings.
  • sayusasugi 7y ago
    Heuristics like this are important because humans are not machines. If you run into a warning in one of these situations, they are usually rectified by changing the statement slightly. Worst case scenario you can #pragma push and pop the warning.
• pmikesell 7y ago
  Yes, or 1 << 31, for example.
  • rocqua 7y ago
    That has plenty of usecases.
• raxxorrax 7y ago
  I don't know if it is a good practice, but I often have statements and expressions that look awfully similar. Flipping bits does happen often enough. Mostly written as y ^ (1 << x), which could easily resolve to these expressions. Mostly at runtime, sure, but there are exceptions. Especially if you like descriptive constants. I would expect it to be quite difficult to separate the "correct cases" without people starting to just suppress compiler warnings or trick it with writing the same stuff in different words (which might be better). On the other hand, setting max_short to something like 18 is probably a really god prank in larger programming environments. The compiler would just ruin all the fun here.
  • derefr 7y ago
    > Mostly written as y ^ (1 << x), which could easily resolve to these expressions. We’re talking about a parse-time check; things that resolve to those values after identifier binding won’t throw the warning. It’s not a warning about what you wrote (semantically), it’s a warning about how you wrote it (syntactically).
  • rocqua 7y ago
    The point is very specifically cases where X is a decimal literal (not an expression such as 1 << x, or a hex number). Things that resolve to this don't trigger the warning, and it is a compile time warning. And then specifically looking at 2^X and 10^X occurring in source code.
    • raxxorrax 7y ago
      I would agree with the suggestion then. It can happen that you just write it out like that and the compiler should maybe inform me. But why limit it to 2^ and 10^ and not say literal^literal should always produce a warning? Any common or valid usages that I am missing here?
      • NotPaidToPost 7y ago
        > But why limit it to 2^ and 10^ and not say literal^literal should always produce a warning? You're suggesting that using the C language as specified and intended should produce a warning... That makes no sense.