22-05-2018, 01:46 PM
It is written in the misra document that the operands for > must be unsigned. In my humble opinion, you are missing something. Semantic type checks are not particularly safe, I claim they are dangerous.
Sanitizers, static analyzers and compilers are checking that the operands are not negative. By following this MISRA advice, these checks are "disabled".
Simple example code:
This is UB so the static analyzers/compilers/sanitizers will write a warning. For instance 1 tool writes:
Shifting a negative value is technically undefined behaviour
If MISRA is enforced then the operand must be casted to unsigned somewhere, the developer might change it to:
Now the tools don't complain. The bug is hidden.
To help prevent some such damage, I have thought about a rule that makes such casts illegal, when there is loss of precision or loss of sign in explicit casts. But that is used by intention sometimes, as far as I know, so it might be noisy.
Sanitizers, static analyzers and compilers are checking that the operands are not negative. By following this MISRA advice, these checks are "disabled".
Simple example code:
Code:
int32_t foo(void)
{
int32_t x = -1;
return x >> 3;
}
This is UB so the static analyzers/compilers/sanitizers will write a warning. For instance 1 tool writes:
Shifting a negative value is technically undefined behaviour
If MISRA is enforced then the operand must be casted to unsigned somewhere, the developer might change it to:
Code:
int32_t foo(void)
{
int32_t x = -1;
return (uint32_t)x >> 3;
}
Now the tools don't complain. The bug is hidden.
To help prevent some such damage, I have thought about a rule that makes such casts illegal, when there is loss of precision or loss of sign in explicit casts. But that is used by intention sometimes, as far as I know, so it might be noisy.
<t></t>