CertC-DCL13

Declare function parameters that are pointers to values not changed by the function as const

Required inputs: IR

Declaring function parameters const indicates that the function promises not to change these values.

In C, function arguments are passed by value rather than by reference. Although a function may change the values passed in, these changed values are discarded once the function returns. For this reason, many programmers assume a function will not change its arguments and that declaring the function's parameters as const is unnecessary. 

void foo(int x) {
  x = 3; /* Visible only in the function */
  /* ... */
}

Pointers behave in a similar fashion. A function may change a pointer to reference a different object, or NULL, yet that change is discarded once the function exits. Consequently, declaring a pointer as const is unnecessary. 

void foo(int *x) {
  x = NULL; /* Visible only in the function */
  /* ... */
}
Noncompliant Code Example

Unlike passed-by-value arguments and pointers, pointed-to values are a concern. A function may modify a value referenced by a pointer argument, leading to a side effect that persists even after the function exits. Modification of the pointed-to value is not diagnosed by the compiler, which assumes this behavior was intended. 

void foo(int *x) {
  if (x != NULL) {
    *x = 3; /* Visible outside function */
  }
  /* ... */
}

If the function parameter is const-qualified, any attempt to modify the pointed-to value should cause the compiler to issue a diagnostic message. 

void foo(const int *x) {
  if (x != NULL) {
    *x = 3; /* Compiler should generate diagnostic message */
  }
  /* ... */
}

As a result, the const violation must be resolved before the code can be compiled without a diagnostic message being issued.

Compliant Solution

This compliant solution addresses the const violation by not modifying the constant argument: 

void foo(const int * x) {
  if (x != NULL) {
    printf("Value is %d\n", *x);
  }
  /* ... */
}
Noncompliant Code Example

This noncompliant 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 *c_str1 = "c_str1";
const char *c_str2 = "c_str2";
char c_str3[9] = "c_str3";
const char c_str4[9] = "c_str4";

strcat_nc(c_str3, c_str2);  /* Compiler warns that c_str2 is const */
strcat_nc(c_str1, c_str3);  /* Attempts to overwrite string literal! */
strcat_nc(c_str4, c_str3);  /* Compiler warns that c_str4 is const */

The function behaves 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 generates a warning about attempting to cast away const on c_str2 because strcat_nc() does not modify its second argument yet fails to declare it const.

In the second strcat_nc() call, the compiler compiles the code with no warnings, but the resulting code will attempt to modify the "c_str1" literal. This violates STR05-C. Use pointers to const when referring to string literals and STR30-C. Do not attempt to modify string literals.

In the final strcat_nc() call, the compiler generates a warning about attempting to cast away const on c_str4, which 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, function parameters 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, but the second argument cannot. 

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

char *c_str1 = "c_str1";
const char *c_str2 = "c_str2";
char c_str3[9] = "c_str3";
const char c_str4[9] = "c_str4";

strcat(c_str3, c_str2);

/* Args reversed to prevent overwriting string literal */
strcat(c_str3, c_str1);
strcat(c_str4, c_str3);  /* Compiler warns that c_str4 is const */

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 because c_str3 is a valid destination string and may be safely modified.

Risk Assessment

Failing to declare an unchanging value const prohibits the function from working with values already cast as const. This problem can be sidestepped by type casting away the const, but doing so violates EXP05-C. Do not cast away a const qualification.

Recommendation Severity Likelihood Remediation Cost Priority Level
DCL13-C Low Unlikely Low P3 L3
Related Guidelines
SEI CERT C++ Coding Standard VOID DCL13-CPP. Declare function parameters that are pointers to values not changed by the function as const
ISO/IEC TR 24772:2013 Passing Parameters and Return Values [CSJ]
MISRA C:2012 Rule 8.13 (advisory)
Excerpt from SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition) and SEI CERT C Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/recommendations/declarations-and-initialization-dcl/dcl13-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key

Text

Severity

Disabled

cafe_message

{}

None

False

parameter_can_point_to_const

{} can be declared as pointer/reference to const.

None

False

unmodified_non_const_ref_collapsed_parameter

{} is not modified, but has type reference to non-const due to reference collapsing.

None

False

Options

check_all_variables

check_all_variables : bool = False

Whether non-parameter variables should be checked as well.
 

check_pointer_types_in_typedefs

check_pointer_types_in_typedefs : bool = False

Whether to check pointer types in typedefs, i.e. 
     typedef int *ptr; int f(ptr p) { return *p; }
 

ignore_forwarding_references

ignore_forwarding_references : bool = True

Whether to allow C++11 forwarding references (universal references) even if all template instances would also work with a const lvalue reference.
 

ignore_move_constructors

ignore_move_constructors : bool = True

Whether to allow non-const rvalue references on constructors.
 

message_predicate

message_predicate

Type: typing.Callable[[Cafe_Message], bool] | None

Default: <bound method Dcl13Rule.const_argument of <bauhaus.rules.cert.c.dcl.certc_dcl13.Dcl13Rule object at 0x7f6f1b321d80>>

If provided, a custom predicate to filter relevant messages. Receives the message node and should return True for messages to report.
 

report_overrides

report_overrides : bool = True

Whether to report violations on overrides.

For virtual methods, this rule will report a violation only if the parameter can be marked const in all related methods in the inheritance hierarchy. Thus, the same violation is reported for each method in the inheritance hierarchy.

You can set this option to false to report such violations only for the base methods.

 

reported_messages

reported_messages : set[int] | None = {137, 167}

If provided, only messages of these types are reported.
 

reported_severities

reported_severities : set[str] = {'error', 'remark', 'warning'}

List of severities to display.
 

transitive_const

transitive_const : bool = False

If this option is enabled, writes to param->some_field->other_field will avoid "could be const" violations for param. The constness of *param is independent of the constness of *param->some_field, allowing such a parameter to be marked const. However, such code is usually mutating data logically belonging to the parameter, so it might be undesirable to mark such parameters as const.

This option also excludes violations if the pointer read from param->some_field is used in any way where a non-const pointer is expected (e.g. passed as parameter or stored in local).

 

use_error_number

use_error_number : bool = False

Whether the error number from the frontend should be used.
 

use_rule_severity

use_rule_severity : bool = True

Whether the rule's severity or the compiler's severity should be used.