Skip to end of metadata
Go to start of metadata

Variables and functions should be declared in the minimum scope from which all references to the identifier are still possible.

When a larger scope than necessary is used, code becomes less readable, harder to maintain, and more likely to reference unintended variables (see DCL01-C. Do not reuse variable names in subscopes).

Noncompliant Code Example

In this noncompliant code example, the function counter() increments the global variable count and then returns immediately if this variable exceeds a maximum value:

unsigned int count = 0;

void counter() {
  if (count++ > MAX_COUNT) return;
  /* ... */

}

Assuming that the variable count is only accessed from this function, this example is noncompliant because it does not define count within the minimum possible scope.

Compliant Solution

In this compliant solution, the variable count is declared within the scope of the counter() function as a static variable. The static modifier, when applied to a local variable (one inside of a function), modifies the lifetime (duration) of the variable so that it persists for as long as the program does and does not disappear between invocations of the function.

void counter() {
  static unsigned int count = 0;
  if (count++ > MAX_COUNT) return;
  /* ... */

}

The keyword static also prevents reinitialization of the variable.

Noncompliant Code Example

The counter variable i is declared outside of the for loop, which goes against this recommendation because it is not declared in the block in which it is used. If this code were reused with another index variable j, but there was a previously declared variable i, the loop could iterate over the wrong variable.

size_t i = 0;

for (i=0; i < 10; i++){
  /* Perform operations */
}

Compliant Solution

Complying with this recommendation requires that you declare variables where they are used, which improves readability and reusability. In this example, you would declare the loop's index variable i within the initialization of the for loop. This requirement was recently relaxed in the C Standard.

for (size_t i=0; i < 10; i++) {
  /* Perform operations */
}

Noncompliant Code Example (Function Declaration)

In this noncompliant code example, the function f() is called only from within the function g(), which is defined in the same compilation unit. By default, function declarations are extern, meaning that these functions are placed in the global symbol table and are available from other compilation units.

int f(int i) {
  /* Function definition */
}

int g(int i) {
  int j = f(i);
  /* ... */
} 

Compliant Solution

In this compliant solution, the function f() is declared with internal linkage. This practice limits the scope of the function declaration to the current compilation unit and prevents the function from being included in the external symbol table. It also limits cluttering in the global name space and prevents the function from being accidentally or intentionally invoked from another compilation unit. See DCL15-C. Declare file-scope objects or functions that do not need external linkage as static for more information.

static int f(int i) {
  /* Function definition */
}

int g(int i) {
  int j = f(i);
  /* ... */
} 

Risk Assessment

Failure to minimize scope could result in less reliable, readable, and reusable code.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

DCL19-C

Low

Unlikely

Medium

P2

L3

Automated Detection

Tool

Version

Checker

Description

Astrée
19.04

local-object-scope

global-object-scope

Partially checked
Axivion Bauhaus Suite

6.9.0

CertC-DCL19
CodeSonar
5.0p0

LANG.STRUCT.SCOPE.FILE
LANG.STRUCT.SCOPE.LOCAL

Scope could be file static
Scope could be local static

ECLAIR

1.2

CC2.DCL19

Fully implemented

LDRA tool suite
 9.7.1
25 D, 61 D, 40 SFully implemented
Parasoft C/C++test
10.4.2

CERT_C-DCL19-a

Declare variables as locally as possible

Polyspace Bug Finder

R2018a

MISRA C:2012 Rule 8.7

MISRA C:2012 Rule 8.9

Functions and objects should not be defined with external linkage if they are referenced in only one translation unit

An object should be defined at block scope if its identifier only appears in a single function

PRQA QA-C
9.5
1504, 1505, 1531, 1532, 3210, 3218
RuleChecker
19.04

local-object-scope

global-object-scope

Partially checked

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines



5 Comments

  1. Just for clarification, can you provide an example of this recommendation applied to a function declaration?

    1. I suspect the answer is that a function declaration

      int foo(int bar, char baz);
      

      should not provide names for its parameters.

      int foo(int, char);
      

      Even better, it can provide them in comments.

      int foo(int /* bar */, char /* baz */);
      
      1. I recall seeing this before, but I don't remember the justification.  It is certainly common practice to name the parameters, see http://stackoverflow.com/questions/8174886/put-name-of-parameters-in-c-function-prototypes

        1. Agreed. While I've seen advice not to name the parms (or to name them in comments), I've never seen this used with much force (eg its very weak). On that StackOverflow page the best reason I can see to name the parms (as opposed to naming them in comments) is that they can be easily harvested by an IDE.

  2. I think it probably was just meant to suggest that functions that were only called from within the compilation unit should be declared as static.  I've added an example.