MISRA C:2012, Rule 21.1:
#define
and#undef
shall not be used on a reserved identifier or reserved macro name.
However, C11 permits to define, for example, __STDC_WANT_LIB_EXT1__
.
Example:
#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
Does it mean that rule 21.1 contradicts with C11?
UPD. Any MISRA-C compliant project cannot use Annex K. This is because per MISRA C:2012 Amendment 2:
Other than defining
__STDC_WANT_LIB_EXT1__
to '0', the facilities of Annex K (Bounds-checking interfaces) shall not be used.
CodePudding user response:
The original MISRA-C:2012 only covers C90 and C99.
As you apparently found out yourself, the MISRA C:2012 AMD2 regarding C11 compatibility pretty much bans all prominent C11 features (Rule 1.4 AMD2.30), including the annex K bounds-checking interface.
I have absolutely no idea why anyone would want to #define __STDC_WANT_LIB_EXT1__ 1
in general, let alone in a safety-related application. The bounds-checking interface has received a lot of critique even from inside the WG14 C committee. You shouldn't need a rule to tell you that it has no place inside a MISRA C application - common sense will get you very far.
As for rule 21.1, the rationale is that people shouldn't run off to create their own magic wrappers with surprising behavior around standard library functions etc. Like #define strcpy(dst, src) strcpy(src, dst)
or similar macro madness that people who like to invent their own "local garage standard" macro languages might come up with.