09-07-2010, 11:23 AM
Consider the following code fragment:
In the above DO_SOMETHING appears to be a (non-null) statement. However this depends on the value of the macro after pre-processing.
If the macro is defined as
then the DO_SOMETHING line is actually a null statement which appears on a line by itself. In order to catch this, the source code before pre-processing must be considered. Pre-processing will simply remove the DO_SOMETHING token sequence.
Rule 14.3 is also designed to catch the accidental use of null statements by the unintentional insertion of a ';'. The non-compliant line is the example above shows how they can lead to unexpected results, as what appears to be the body of the if statement will always be executed.
Code:
void fn ( bool_t b )
{
if ( b ); /* Non-compliant */
{
DO_SOMETHING;
}
}
If the macro is defined as
Code:
#define DO_SOMETHING
Rule 14.3 is also designed to catch the accidental use of null statements by the unintentional insertion of a ';'. The non-compliant line is the example above shows how they can lead to unexpected results, as what appears to be the body of the if statement will always be executed.
Posted by and on behalf of the MISRA C Working Group