The rule gets triggered 3 times in the following code, with the & operator...
According to the rules of the standard, 0x1F is a signed constant, yet it does not differ from its unsigned equivalent, and maybe we should exclude positive signed constants from this rule.- Positive constants are already handled
src is unsigned, 3 is a positive number, but src >> 3 is a signed integer according to the language rules. Therefore, (src >> 3) & 0x1F is considered as an issue.
To remove this FP, we should not only look at the type of the operands of a bitwise operation, but go to the leafs of a full bitwise expression, and if all those leafs have the right type, not report the issue. (this is similar to what the essential type model of MISRA is trying to achieve).
Additionally, it looks like the rules about bitwise operations have changed in C++20, so we should revisit if this rule still makes sense...