bugprone-switch-missing-default-case false positives

[nick-potenski]

The bugprone-switch-missing-default-case checker can present false positive findings when a switch's case statement is logically complete even though the switch does not use an enum value.

For example:

int foo(unsigned int in) {
    switch (in % 4) {
        case 0:
        case 1:
        case 2:
        case 3:
            return 1;
    }

    return 0;
}

yields

warning: switching on non-enum value without default case may not cover all cases [bugprone-switch-missing-default-case]
    3 |     switch (in % 4) {
      |     ^
1 warning generated.

Compiler explorer link.

FWIW, I understand that the checker's documentation specifically states that it is only looking for the intersection of non-enum switches and missing default cases, so I can understand why my report may be out of scope. It won't hurt my feelings if you want to reject this or file it as an improvement rather than a bug.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Nick Potenski (nick-potenski)

The bugprone-switch-missing-default-case checker can present false positive findings when a switch's case statement is logically complete even though the switch does not use an enum value.

For example:

int foo(int in) {
    switch (in % 4) {
        case 0:
        case 1:
        case 2:
        case 3:
            return 1;
    }

    return 0;
}

yields

warning: switching on non-enum value without default case may not cover all cases [bugprone-switch-missing-default-case]
    3 |     switch (in % 4) {
      |     ^
1 warning generated.

Compiler explorer link.

FWIW, I understand that the checker's documentation specifically states that it is only looking for the intersection of non-enum switches and missing default cases, so I can understand why my report may be out of scope. It won't hurt my feelings if you want to reject this or file it as an improvement rather than a bug.

[LegalizeAdulthood]

I would agree with @EugeneZelenko that it's a false positive; the check shouldn't trigger in this situation IMO.

[localspook]

The switch in your example might not be the best one to demonstrate the issue, because that one doesn't actually cover all cases. The range of in % 4 is [-3, 3], not [0, 3], because the modulo operator in C and C++ doesn't behave like the mathematical one for negative integers (it behaves like the one implemented in hardware). Again, I'm not saying this issue is invalid, just that this might not be the best example (a better one would be with unsigned int instead of int).

[nick-potenski]

Aww, thanks @localspook! I fixed it to use unsigned int, which is more in line with what I encountered this with on our codebase.