4 ms·

It would be nice, but I can see it's not easy to come up with a warning heuristic that doesn't give a bunch of false positives. Sure, 2^16 is "obviously" wrong,

It would be nice, but I can see it's not easy to come up with a warning heuristic that doesn't give a bunch of false positives. Sure, 2^16 is "obviously" wrong, but how about SOMETHING ^ XOR_KEY with #define SOMETHING and #define XOR_KEY 16?

DaiPlusPlus 7y ago
They discuss that in the thread. Consensus seems to be to warn when seeing “2 ^ (certain base-10 literals)”. It’s uncommon to use base 10 when bit-twiddling with the XOR operator - so this makes sense. Of course, it would be better if C-family languages didn’t use ^ for XOR in the first place.
- mehrdadn 7y ago
  Do they not currently/do they plan to track macro expansion well enough to distinguish between macros and literals? I feel like they should be able to get the best of both worlds here.
- simias 7y ago
  >Of course, it would be better if C-family languages didn’t use ^ for XOR in the first place. I think at the time they were created there simply wasn't an ambiguity in anybody's mind. POW is a relatively complex operation, I don't think anybody expected it as a builtin operator (much like SQRT and friends). Arguably so is DIV but I suppose that's too convenient not to have. XOR on the other hand is something you really want to be a builtin operator in a low level, bit-twiddling language like C, so getting a dedicated operator makes sense. I'm not sure if an other sigil would've made more sense, after all ASCII lacks ⊕.
  - dehrmann 7y ago
    > I think at the time they were created there simply wasn't an ambiguity in anybody's mind. And why would anyone in their right mind do 23 and not 1<<3? At least among the crowd who knows pow is expensive and what xor is.
  - beezle 7y ago
    Algol 68 and Fortran both had . In fact, COBOL 60 even supported so not sure why anyone would not expect it as builtin for C.
- billpg 7y ago
  If we're using our time machines to fix C, can we make a special type that's identical to unsigned int but can use all the bit-wise operators, requiring an explicit conversion operators between regular int and bitwise int. bitwise x = 0x1234; x |= 0x1000; (0x indicates a bitwise value.)
  - colejohnson66 7y ago
    I wouldn’t use 0x as that is used commonly to refer to hexadecimal values. Unless that was your intent and those are hexadecimal
    - billpg 7y ago
      That was indeed my intention. Remember we're hypothetically reinventing C from scratch so there's no legacy code to worry about. By making 0x literals of bitwise type, they can only be used with bitwise operators. Decimal literals are regular integers so can only use arithmetic operators. If you want to use a hexadecimal value with arithmetic operators or decimal values with bitwise operators, use the operator that converts one type to another.
Jyaif 7y ago
With clang you can write linters that get the AST of the code in input. https://clang.llvm.org/extra/clang-tidy/ https://clang.llvm.org/extra/clang-tidy/

DaiPlusPlus 7y ago

They discuss that in the thread. Consensus seems to be to warn when seeing “2 ^ (certain base-10 literals)”. It’s uncommon to use base 10 when bit-twiddling with the XOR operator - so this makes sense. Of course, it would be better if C-family languages didn’t use ^ for XOR in the first place.

mehrdadn 7y ago
Do they not currently/do they plan to track macro expansion well enough to distinguish between macros and literals? I feel like they should be able to get the best of both worlds here.
simias 7y ago
>Of course, it would be better if C-family languages didn’t use ^ for XOR in the first place. I think at the time they were created there simply wasn't an ambiguity in anybody's mind. POW is a relatively complex operation, I don't think anybody expected it as a builtin operator (much like SQRT and friends). Arguably so is DIV but I suppose that's too convenient not to have. XOR on the other hand is something you really want to be a builtin operator in a low level, bit-twiddling language like C, so getting a dedicated operator makes sense. I'm not sure if an other sigil would've made more sense, after all ASCII lacks ⊕.
- dehrmann 7y ago
  > I think at the time they were created there simply wasn't an ambiguity in anybody's mind. And why would anyone in their right mind do 23 and not 1<<3? At least among the crowd who knows pow is expensive and what xor is.
- beezle 7y ago
  Algol 68 and Fortran both had . In fact, COBOL 60 even supported so not sure why anyone would not expect it as builtin for C.
billpg 7y ago
If we're using our time machines to fix C, can we make a special type that's identical to unsigned int but can use all the bit-wise operators, requiring an explicit conversion operators between regular int and bitwise int. bitwise x = 0x1234; x |= 0x1000; (0x indicates a bitwise value.)
- colejohnson66 7y ago
  I wouldn’t use 0x as that is used commonly to refer to hexadecimal values. Unless that was your intent and those are hexadecimal
  - billpg 7y ago
    That was indeed my intention. Remember we're hypothetically reinventing C from scratch so there's no legacy code to worry about. By making 0x literals of bitwise type, they can only be used with bitwise operators. Decimal literals are regular integers so can only use arithmetic operators. If you want to use a hexadecimal value with arithmetic operators or decimal values with bitwise operators, use the operator that converts one type to another.

Jyaif 7y ago

With clang you can write linters that get the AST of the code in input. https://clang.llvm.org/extra/clang-tidy/ https://clang.llvm.org/extra/clang-tidy/