switch (p_length) // the input’s length as a size_t
{
case 0:
return FuncResult::Nil;
case 1:
auto rank = p_stats[0];
if (p_input_clamp)
rank = ClampTo0_1_NaNTo0(rank);
*p_rank = rank;
return FuncResult::Normal;
}
Per the documentation:
For completeness, a switch over the values of an enum must either address each value in the enum or contain a default case. switch statements that are not over enum must end with a default case.
Could you try to formulate your concern as a question? I’m not quite sure if I understand the problem at hand.
Indeed, processing an enum in a switch must either handle all possible values of that enum or—in case you process an integer value like in your example—end with a default case. Your code snippet will trigger rule S3562 and the analyzer suggests adding a default case as stated in the second point of the documentation.
My concern is: Why is rule S3562, which applies only to enumerations, act on standard integers? This creates false positives because the application of the rule doesn’t exclusively follow the rule’s definition.
As in my example, it can be useful (and create more readable code) to use a switch for lengths and other non-enum cases. Adding a default case in such scenarios would be an instance of working work the code analyzer, which is backward.
Put another way, why would a non-enum mandatorily require a default case?
Got it. Yes, working the analyzer is backward and should be avoided.
However, in the documentation for that rule, it also says that
switch statements that are not over enum must end with a default case.
If you process an integer-typed variable using a switch like in your example, the variable could potentially subsume any value in [−2,147,483,648, 2,147,483,647] assuming a 4 bytes signed integer, for instance. Since a switch is unlikely to handle all of those many cases, everything that is not handled should be addressed in a default case. We feel this is reasonable, since switch constructs are typically used to handle many cases, it is just too easy to miss one. If you, on the other hand, only have two or three cases to handle, think about using ordinary if/else (if), instead.
It seems like that for your code, you have some domain knowledge and can be sure that p_length can only be either 0 or 1. In that case, you can mark this analyzer finding as a won’t fix with a quick comment that the construct is safe in that instance. Or replace it with an ordinary if/else.
My mistake. I didn’t see the final part of the documentation. I typically use switch to test for several lengths, but I can see why a series of ifs would be better.