DCL00-A. Const-qualify immutable objects

Immutable objects should be const-qualified. Enforcing object immutability using const-qualification helps ensure the correctness and security of applications. ISO/IEC PDTR 24772, for example, recommends labeling parameters as constant to avoid the unintentional modification of function arguments [[ISO/IEC PDTR 24772]]. [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.

Macros, or an enumeration constant, may also be used instead of a const-qualified object. DCL06-A. Use meaningful symbolic constants to represent literal values in program logic describes the relative merits of using const-qualified objects, enumeration constants, and object-like macros. However, adding a const qualifier to an existing variable is a better first step than replacing the variable with an enumeration constant or macro, because the compiler will issue warnings on any code that changes your const-qualified variable. Once you have verified that a const-qualified variable is not changed by any code, you may consider changing it to an enumeration constant or macro, as best fits your design.

Non-Compliant Code Example

In the following non-compliant code, 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.

float const pi = 3.14159f;
float degrees;
float radians;
/* ... */
radians = degrees * pi / 180;

Automated Detection

Compass/ROSE could detect violations of this rule by flagging any variable as a violation as long as:

• the variable is local to a function, or static (but not extern)
• It is never assigned to
• Its address is never evaluated.
  These violations will be genuine, but ROSE can't catch all violations. In particular:
• A variable whose address is taken might still be const
• Variables appearing in multiple files might still be const.
• Doesn't handle constant data on the heap

Risk Assessment

Failing to const-qualify immutable objects can result in a constant being modified at runtime.

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]]

02. Declarations and Initialization (DCL)      02. Declarations and Initialization (DCL)       DCL01-A. Do not reuse variable names in subscopes