
If one definition affects another, encode the relationship in the definition; do not give two independent definitions. A corollary of this recommendation is not to encode transitory relationships in definitions.
Non-Compliant Coding Example
In this non-compliant coding, the definition for XX2
must always be two greater than the definition of XX
. The following definitions fail to embody this relationship:
#define XX 5 #define XX2 7 /* misleading, no indication of relationship */
Consequently, a programmer performing maintenance on this program would need to identify the relationship and modify both definitions accordingly. While this sort of error appears relatively benign, it could easily lead to serious security vulnerabilities such as buffer overflows.
Compliant Solution
This pair of definitions embodies the relationship between the two definitions.
#define XX 5 #define XX2 (XX + 2)
As a result, a programmer could reliably modify the program by changing the definition of XX
.
Non-Compliant Coding Example
In this non-compliant coding, a relationship is established between two constants where none exits:
#define ADULT_AGE 18 #define PURCHASE_ALCOHOL_AGE (ADULT_AGE + 3) /* misleading, relationship established when none exists */
Consequently, a programmer performing maintenance on this program may modify the definition for ADULT_AGE
but fail to recognize that the definition for PURCHASE_ALCOHOL_AGE
has also been changed as a consequence.
Compliant Solution
This compliant solution does not assume a relationship when none exists:
#define ADULT_AGE 18 #define PURCHASE_ALCOHOL_AGE 21
Risk Assessment
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
PRE07-A |
1 (low) |
1 (unlikely) |
2 (medium) |
P2 |
L3 |
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[Plum 85]] Rule 1-4
[[ISO/IEC 9899-1999]] Section 6.10, "Preprocessing directives," and Section 5.1.1, "Translation environment"