Question

我试图从我的代码中删除违规规则16.1。

示例代码：

switch (cmd) {
    case ADD:
        result = add(op1, op2);
        break;
    case SUB: 
        if (!flag) {    // Problem here!
            break;     
        }
        //Fallthrough
    case ALU_CMD_SUB:
        result = sub(op1, op2);
        .
        .
        .
        .
        .
        .

        break;
    case ALU_CMD_DIV:
        result = divide(op1, op2);
        break;
    case ALU_CMD_EXP:
        result = (int32_t)expo((uint32_t)op1, (uint32_t)op2);
        break;
    default:
        incr_default(&default_cond);
        //fix for the violation: insert a break statement
        break;
}

这里带有SUB的开关盒没有很好地形成。

有没有办法解决这个问题而代码中没有太多噪音。

这也违反了规则16.3，其中switch case没有break语句。

Answer 1

在符合MISRA法律规则（规则16.3）的情况下，您可以考虑：

switch (cmd) {
    case ADD:
        result = add(op1, op2);
        break;
    case SUB: 
    case ALU_CMD_SUB:
        if (cmd == SUB && !flag) {
            break;     
        }
        result = sub(op1, op2);
        .
        .
        .    
        break;
    …
}

或者也许：

switch (cmd) {
    case ADD:
        result = add(op1, op2);
        break;
    case SUB: 
    case ALU_CMD_SUB:
        if (cmd == ALU_CMD_SUB || flag) {
            result = sub(op1, op2);
            .
            .
            .
        }
        break;
    …
}

Answer 2

这个问题最简单的答案，如果确实是故意的，那就是提出一个偏差。

试图通过尝试编写聪明的代码来规避规则，使事情变得不那么清晰，并且可维护性较差 - 偏差清楚地说明了你想要做什么，并且意味着未来的维护者不会犯错误。

另外，对于下一版C标准，建议添加注释[[fallthrough]]以表明这是预期的行为！我很确定MISRA C会在发布后立即识别出这个属性，并且规则16.3更新......

Answer 3

Fall through是C中的有效构造 - 它可以提高代码效率。拥有大量经验的乐趣之一就是知道什么时候可以打破“规则”。在这种情况下，良好的工程和代码安全性很重要（*），请记录此规则在此时被破坏的原因。

我假设在这种情况下，不应在if !flag下检查ALU_CMD_SUB元素，并且SUB元素是执行ALU_CMD_SUB元素的有效前导

（*）采用MISRA意味着对代码安全的要求越来越高。

MISRA C 2012规则16.1所有开关声明都应该形成良好

3 个答案: