這種結構是否需要偏離 MISRA C 2012 和 2020？
#include <stdio.h>
#define ONE 1
#define TWO 2
#define OOPS 42
#define INNER_DEF_BAR(x) (bar_##x)
#define DEF_BAR(x) void INNER_DEF_BAR(x)(void)
DEF_BAR(ONE);
DEF_BAR(TWO);
DEF_BAR(OOPS);
DEF_BAR(ONE)
{
printf("one\n");
}
DEF_BAR(TWO)
{
printf("two\n");
}
DEF_BAR(OOPS)
{
printf("42\n");
}
int main()
{
bar_1();
bar_2();
bar_42();
return 0;
}
例如，在 MISRA C 2012 中，我對以下句子感到困惑
規則 20.7 宏引數擴展產生的運算式應括在括號中
并且這個執行緒的結論是關于 X-macros beeeing 可能沒有偏差，因為只違反了咨詢規則。
uj5u.com熱心網友回復：
使用宏來宣告/定義函式在任何系統中都是非常有問題的做法，尤其是關鍵系統。據我所知，這并不是明確的（強制性/必需的）MISRA 違規，但是這樣的代碼不可能通過任何代碼審查，更不用說任何半體面的功能安全評估員了。沒有什么比發明My Little Macro Language更能激怒代碼審查者的方法了，然后強迫他們學習它。
從嚴格的 MISRA C 角度來看，您違反了關于使用類似函式的宏的建議性指令 4.9 和關于使用##運算子的建議性規則 20.10。確實，您不需要正式偏離建議規則，但您仍然需要就您這樣做的原因提出論據。理想情況下，這應該在公司編碼指南級別，說明哪些咨詢規則被忽略以及哪些咨詢規則被強制執行。也就是說，要么您從所有靜態分析中過濾掉某個咨詢規則，要么您將“提升”它并像對待任何必需規則一樣對待它。
X 宏和類似函式的宏通常是有問題的，但您可以以結構化的“事實上的標準”方式使用它們。可以爭論為什么他們會在特定場景下改進代碼。
我真誠地懷疑您是否可以為為什么函式名稱生成應該在關鍵程式中使用類似函式的宏來完成提出合理的論據。這樣的程式必須是確定性的，在宏后面沒有隱藏任何意外。特別是不應該允許型別通用或“模板”編程。所以IMO只有兩個合適的解決方案：
- 洗掉宏，然后輸入/硬編碼所有內容，或者
- 洗掉宏并使用在編譯和靜態分析之前運行的腳本預生成源代碼。
其他任何事情都是非常值得懷疑的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/520279.html
標籤：C静态分析米斯拉
上一篇：C-如何將數字的數字拆分為陣列？