4

I have two use case for this Misra warning as mentioned below. Does compiler reserve some or specific name for #if defines which can't be used?

Currently, I have disabled this warning by //lint !e9071 but do we really need to do anything for such warnings? Is there any impact or risk if we disabled such warnings?

Case 1:

#ifndef __CCPPAR_H__
#define __CCPPAR_H__    //lint !e9071


#include "Ccp_Cfg.h"

#endif /* multiple inclusion protection - __CCPPAR_H__ */

Observed warning: 

defined macro '__CCPPAR_H__' is reserved to the compiler [MISRA 2012
Rule 21.1, required]

Case 2: 

#ifndef __CCP_H__
#define __CCP_H__    //lint !e9071

#include "Ccppar.h"

#define MAJOR   0x02
#define MINOR   0x01

/* other parts of code */ 

#endif

Observed below Misra warnings:

defined macro '__CCP_H__' is reserved to the compiler [MISRA 2012
Rule 21.1, required]
Lundin
  • 195,001
  • 40
  • 254
  • 396
kapilddit
  • 1,729
  • 4
  • 26
  • 51
  • `Does compiler reserve some or specific name for #if defines which can't be used?` - yes – KamilCuk Aug 22 '19 at 13:55
  • 2
    Just do some research on "reserved identifiers" in C. – Ulrich Eckhardt Aug 22 '19 at 13:55
  • Note that you should not, in general, create function, variable, tag or macro names that start with an underscore. Part of [C11 §7.1.3 Reserved identifiers](https://port70.net/~nsz/c/c11/n1570.html#7.1.3) says: — _All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use._ — _All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces._ See also [What does double underscore (`__const`) mean in C?](https://stackoverflow.com/a/1449301) – Jonathan Leffler Aug 22 '19 at 14:35
  • @JonathanLeffler: Thanks for beautifying my answer, which I've wiki'd out of courtesy. – Bathsheba Aug 22 '19 at 15:15
  • 1
    @Bathsheba: You're welcome. The switch to CW wasn't necessary, but it's a nice touch; thank you. I have a little shell script that generates the text in my comment, which I copied into your answer — it's a problem I see often enough that I've standardized my response. It isn't always the main topic of the question; indeed, usually it is tangential to the issue raised in the question, so a comment is appropriate. – Jonathan Leffler Aug 22 '19 at 15:18
  • 1
    To clarify, in this case MISRA-C is merely insisting that you follow the C standard. So this is not a rule unique to MISRA - any C compiler is free to give you the same error. – Lundin Aug 23 '19 at 06:42

1 Answers1

7

The C standard, let alone MISRA, reserves all tokens starting with a double underscore.

The practical risk you run is your C standard library implementation using that symbol or even the compiler itself, which clashes with yours.

Part of C11 §7.1.3 Reserved identifiers says:

  • All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
  • All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

See also What does double underscore (__const) mean in C?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • Changing the name of #define is a better solution to avoid any risk? – kapilddit Aug 22 '19 at 13:59
  • 2
    @kapilddit: It's the *only* solution! – Bathsheba Aug 22 '19 at 14:00
  • 1
    Also worth mentioning that identifiers starting with a single underscore followed by a capital letter are reserved, too. – Christian Gibbons Aug 22 '19 at 14:35
  • 3
    To further clarify, the practice of incorrectly naming inclusion-guard macros like this seems to come from just looking at what the standard library headers do and copying it. That's wrong. The standard library headers are part of the implementation, and not only can but **must** use macros in the reserved namespace, since they can't use anything reserved to the application. The application (which includes any third-party library source not part of the standard library) **must not** use these reserved names, and should instead just pick things unlikely to clash with other application code. – R.. GitHub STOP HELPING ICE Aug 22 '19 at 15:51
  • @R.. That is exactly what lead me to doing it incorrectly until I discovered the clause about reserved identifiers. – Christian Gibbons Aug 22 '19 at 16:20