Immutable objects should be const-qualified. Enforcing object immutability using const-qualification helps ensures the correctness and security of applications. ISO/IEC PDTR 24772 [[ISO/IEC PDTR 24772]], for example, recommends labeling parameters as constant to avoid the unintentional modification of function arguments. [STR05-A. Use pointers to const when referring to string literals] describes a specialized case of this recommendation.
Adding const qualification may propagate through a program; as you add const qualifiers, still more become necessary. This phenomenon is sometimes called "const-poisoning." Const-poisoning can frequently lead to violations of EXP05-A. Do not cast away a const qualification. While const qualification is a good idea, the costs may outweigh the value in the remediation of existing code.
One may wish to consider using a macro, or an enumeration constant, rather than a const variable, see DCL06-A. Use meaningful symbolic constants to represent literal values in program logic for details regarding macros vs. enumeration constants vs. const variables. However, adding a const qualifier to a pre-existing variable is a better first step than replacing the variable with an enumeration constant or macro, because the compiler can then issue warnings on any code that changes your const variable. Once you have verified that a const variable indeed is not changed by any code, you may then consider changing it to an enumeration constant or macro, as best fits your design.
Non-Compliant Code Example
In this non-compliant code example, pi is declared as a float. Although pi is a mathematical constant, its value is not protected from accidental modification.
float pi = 3.14159f; float degrees; float radians; /* ... */ radians = degrees * pi / 180;
Compliant Solution
In this compliant solution, pi is declared as a const-qualified object.
const float pi = 3.14159f; float degrees; float radians; /* ... */ radians = degrees * pi / 180;
Risk Assessment
Failing to const-qualify immutable objects can result in a constant being modified at runtime.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
DCL00-A |
1 (low) |
1 (unlikely) |
1 (high) |
P1 |
L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[ISO/IEC 9899-1999]] Section 6.7.3, "Type qualifiers"
[[Saks 00]] Dan Saks. Numeric Literals
. Embedded Systems Programming. September, 2000.
02. Declarations and Initialization (DCL) 02. Declarations and Initialization (DCL) DCL01-A. Do not reuse variable names in subscopes