Header guards shall not use reserved identifiers.

Problem Description: Some header guards (#ifndef BEID_SOMENAME_H #define ...) use reserved identifiers. That's invalid in both C and C++. In objective-c I assume it's invalid too, though I haven't read that standard.

Identifiers that are reserved include:

Identifiers that contain __ (double underscore) anywhere in them.
Identifiers beginning with an underscore followed by a capital letter. Identifiers beginning with an underscore in the global namespace (c++).
Identifiers beginning with 'str', 'is', 'mem', etc, …, followed by a lowercase letter. [C11 Standard: ISO/IEC 9899:2011] Rule 3 applies to C++ but only in the global namespace.

Note that the list isn't exhaustive. You can find more on cppreference.com.

Current Behavior: The code may or may not produce a program that may or may not perform any or all of the intended actions. The standard provides no guarantee about the behavior of invalid code, the behavior is explicitly undefined. The c++ standard committee refers to this as "Ill Formed, No Diagnosis Required", I refer to this as "an absurdly easy to overlook fundamental issue", or "bug in the standard" (don't tell them I said that).

For Example: The software might behave in a way that isn't expected in one of either the debug or the release builds. If it's the former it's a waste of time, if it's the latter it's massive security and liability nightmare. Potential bugs emanating from this may be untraceable, irreproducible (aka "heisenbug").

Expected Behavior: The behavior of an identical program that doesn't (un)define any reserved identifiers.

Proposed Fix: Replacing the aforementioned names with similar but valid names. ie: https://github.com/Fedict/eid-mw/blob/96b8f18c48f4f977cf61fdf08959f2f1fef97aae/cardcomm/pkcs11/src/asn1.h#L21-L22 Could be:

 #ifndef FEDICT_EIDMW_CARDCOMM_PKCS11_SRC_ASN1_H
 #define FEDICT_EIDMW_CARDCOMM_PKCS11_SRC_ASN1_H
 // ...
 #endif

Fedict / eid-mw

Header guards shall not use reserved identifiers. #151