Does MISRA C:2012 rule 21.1 contradict with C11?

Question

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.

Answer 1

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.

Answer 2

Notwithstanding the specifics of your intended use of __STDC_WANT_LIB_EXT1__, Rule 20.1 seeks to prevent accidental or deliberate (re)definition of reserved macros.

Any intended (re)definition is permitted by means of a deviation - which requires the user to justify what they are doing.

If you really want to use Annex K (and @Lundin already addresses the reasons why you probably shouldn't), you can do so - by deviating Rule 20.1 to redefine __STDC_WANT_LIB_EXT1__ and Rule 1.4 to revoke the blanket restriction currently in place. This deviation will require you to show that you understand the problems with Annex K, and what you are doing to prevent the dubious behaviours.

As a footnote, the current position of the MISRA C WG is that the restriction on Annex K is likely to remain, at least until wg14 agree on a path forward.

Disclaimer: See profile for my affiliation