DCL00-A. Const-qualify immutable objects

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. Prefer making string literals const-qualified] 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.

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;

Non-Compliant Code Example

This non-compliant code example, defines a fictional version of the standard strcat() function called strcat_nc(). This function differs from strcat() in that the second argument is not const-qualified.

char *strcat_nc(char *s1, char *s2);

char *str1 = "str1";
const char *str2 = "str2";
char str3[] = "str3";
const char str4[] = "str4";

strcat_nc(str3, str2);
strcat_nc(str1, str3); 
strcat_nc(str4, str3);

The function would behave the same as strcat(), but the compiler generates warnings in incorrect locations, and fails to generate them in correct locations.

In the first strcat_nc() call, the compiler will generate a warning about attempting to cast away const on str2. This is a good warning, as strcat_nc() does not modify its second argument, yet fails to declare it const.

In the second strcat_nc() call, the compiler will happily compile the code with no warnings, but the resulting code will attempt to modify the "str1" literal, which may be impossible; the literal may not be defined in the heap. This violates STR05-A. Prefer making string literals const-qualified.

In the final strcat_nc() call, the compiler generates a warning about ateempting to cast away const on str4. This is a valid warning.

Compliant Solution

This compliant solution uses the prototype for the strcat() from C90. Although the restrict type qualifier did not exist in C90, const did. In general, the arguments should be declared in a manner consistent with the semantics of the function. In the case of strcat(), the initial argument can be changed by the function while the second argument cannot.

char *strcat(char *s1, const char *s2); 

char *str1 = "str1";
const char *str2 = "str2";
char str3[] = "str3";
const char str4[] = "str4";

strcat(str3, str2);  
strcat(str1, str3);  /* Note: reversed args */
strcat(str4, str3);  /* different 'const' qualifiers */

The const-qualification of the second argument s2 eliminates the spurious warning in the initial invocation, but maintains the valid warning on the final invocation in which a const-qualified object is passed as the first argument (which can change). Finally, the middle strcat() invocation is now valid, as str1 is a valid destination string, as the string exists on the stack and may be safely modified.

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.3.2.1, "Lvalues, arrays, and function designators," Section 6.7.2.2, "Enumeration specifiers," and Section 6.10.3, "Macro replacement"
[[ISO/IEC PDTR 24772]] "CSJ Passing parameters and return values"
[[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