MISRA C:2012，規則 21.1：
#define并且#undef不得用于保留的識別符號或保留的宏名稱。
但是，C11 允許定義，例如__STDC_WANT_LIB_EXT1__.
例子：
#define __STDC_WANT_LIB_EXT1__ 1 /* violation of MISRA C:2012, rule 21.1 */
#include <stdio.h>
#ifdef __STDC_LIB_EXT1__
/* tmpfile_s is available */
#endif
這是否意味著規則 21.1 與 C11 相矛盾？
UPD。任何符合 MISRA-C 的專案都不能使用附件 K。這是因為根據 MISRA C:2012 修正案 2：
除了定義
__STDC_WANT_LIB_EXT1__為“0”外，不得使用附件 K（邊界檢查介面）的設施。
uj5u.com熱心網友回復：
最初的 MISRA-C:2012 僅涵蓋 C90 和 C99。
正如您自己發現的那樣，關于 C11 兼容性的 MISRA C:2012 AMD2 幾乎禁止了所有突出的 C11 功能（規則 1.4 AMD2.30），包括附件 K 邊界檢查介面。
我完全不知道為什么任何人都會想要#define __STDC_WANT_LIB_EXT1__ 1，更不用說在與安全相關的應用程式中了。邊界檢查介面甚至在 WG14 C 委員會內部也受到了很多批評。您不需要一條規則來告訴您它在 MISRA C 應用程式中沒有位置 - 常識會讓您走得很遠。
至于規則 21.1，其基本原理是人們不應該跑去創建自己的魔法包裝器，圍繞標準庫函式等具有令人驚訝的行為。喜歡#define strcpy(dst, src) strcpy(src, dst)發明自己的“本地車庫標準”宏語言的人喜歡或類似的宏瘋狂可能會想出。
uj5u.com熱心網友回復：
盡管您對 . 的預期用途有具體規定__STDC_WANT_LIB_EXT1__，但規則 20.1 旨在防止意外或故意（重新）定義保留的宏。
通過偏差允許任何預期的（重新）定義 - 這需要用戶證明他們正在做的事情。
如果您真的想使用附件 K（并且@Lundin 已經解決了您可能不應該使用的原因），您可以這樣做 - 通過偏離規則 20.1 重新定義__STDC_WANT_LIB_EXT1__和規則 1.4 撤銷當前實施的全面限制。這種偏差將要求您表明您了解附件 K 的問題，以及您正在采取哪些措施來防止可疑行為。
作為一個腳注，MISRA C WG 目前的立場是，對附件 K 的限制可能會繼續存在，至少在 wg14 就前進的道路達成一致之前。
免責宣告：查看我的隸屬關系的個人資料
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/473159.html
上一篇：在C（或C ）中更改宏