Main Content

CWE Rule 456

Missing Initialization of a Variable

Since R2024a

Description

Rule Description

The product does not initialize critical variables, which causes the execution environment to use unexpected values.

Polyspace Implementation

The rule checker checks for these issues:

  • Errno not reset

  • Member not initialized in constructor

  • Non-initialized pointer

  • Non-initialized variable

Examples

expand all

Issue

This issue occurs when you do not reset errno before calling a function that sets errno to indicate error conditions. However, you check errno for those error conditions after the function call.

Risk

An errno-setting function sets errno to nonzero values to indicate error conditions.

If you do not set errno to zero before calling an errno-setting function,a nonzero value of errno might be left over from a previous call to an errno-setting function. Using errno to check errors can then lead you to falsely conclude that an error occurred from the most recent call.

errno is set to 0 at program startup but is not automatically reset after an error occurs. You must explicitly set errno to 0 when required.

Fix

Before calling a function that sets errno to indicate error conditions, reset errno to zero explicitly.

Example — errno Not Reset Before Call to strtod
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <float.h>

#define fatal_error() abort()

double func(const char *s1, const char *s2)
{
    double f1;
    f1 = strtod (s1, NULL);       //Noncompliant
    if (0 == errno) {        
      double f2 = strtod (s2, NULL); 
        if (0 == errno) {        
            long double result = (long double)f1 + f2;
            if ((result <= (long double)DBL_MAX) && (result >= (long double)-DBL_MAX)) 
				  {
                return (double)result;
            }
        }
    }
    fatal_error();
    return 0.0;
}

In this example, errno is not reset to 0 before the first call to strtod. Checking errno for 0 later can lead to a false positive.

Correction — Reset errno Before Call

One possible correction is to reset errno to 0 before calling strtod.

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <float.h>

#define fatal_error() abort()

double func(const char *s1, const char *s2)
{
    double f1;
    errno = 0;                   
    f1 = strtod (s1, NULL);
    if (0 == errno) {            
      double f2 = strtod (s2, NULL);  
        if (0 == errno) {       
            long double result = (long double)f1 + f2;
            if ((result <= (long double)DBL_MAX) && (result >= (long double)-DBL_MAX)) 
  			{
                return (double)result;
            }
        }
    }
    fatal_error();
    return 0.0;
}
Issue

This issue occurs when a class constructor has at least one execution path on which it does not initialize some data members of the class.

The defect does not appear in the following cases:

  • Empty constructors.

  • The non-initialized member is not used in the code.

Risk

The members that the constructor does not initialize can have unintended values when you read them later.

Initializing all members in the constructor makes it easier to use your class. If you call a separate method to initialize your members and then read them, you can avoid uninitialized values. However, someone else using your class can read a class member before calling your initialization method. Because a constructor is called when you create an object of the class, if you initialize all members in the constructor, they cannot have uninitialized values later on.

Fix

The best practice is to initialize all members in your constructor, preferably in an initialization list.

Example — Non-Initialized Member
class MyClass {
public:
    explicit MyClass(int);
private:
    int _i;
    char _c;
};

MyClass::MyClass(int flag) {
    if(flag == 0) {
        _i = 0;
        _c = 'a';
    }
    else {
        _i = 1;
    }
} //Noncompliant

In this example, if flag is not 0, the member _c is not initialized.

The defect appears on the closing brace of the constructor. Following are some tips for navigating in the source code:

  • On the Result Details pane, see which members are not initialized.

  • To navigate to the class definition, right-click a member that is initialized in the constructor. Select Go To Definition. In the class definition, you can see all the members, including those members that are not initialized in the constructor.

Correction — Initialize All Members on All Execution Paths

One possible correction is to initialize all members of the class MyClass for all values of flag.

class MyClass {
public:
    explicit MyClass(int);
private:
    int _i;
    char _c;
};

MyClass::MyClass(int flag) {
    if(flag == 0) {
        _i = 0;
        _c = 'a';
    }
    else {
        _i = 1;
        _c = 'b';
    }
}
Issue

This issue occurs when a pointer is not assigned an address before dereference.

Risk

Unless a pointer is explicitly assigned an address, it points to an unpredictable location.

Fix

The fix depends on the root cause of the defect. For instance, you assigned an address to the pointer but the assignment is unreachable.

Often the result details (or source code tooltips in Polyspace as You Code) show a sequence of events that led to the defect. You can implement the fix on any event in the sequence. If the result details do not show this event history, you can search for previous references of variables relevant to the defect using right-click options in the source code and find related events. See also Interpret Bug Finder Results in Polyspace Desktop User Interface or Interpret Bug Finder Results in Polyspace Access Web Interface (Polyspace Access).

See examples of fixes below. It is a good practice to initialize a pointer to NULL when declaring the pointer.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

Extend Checker

If a pointer in your code is non-initialized only for certain system input values, you can see one possible combination of input values causing the defect. See Extend Bug Finder Checkers to Find Defects from Specific System Input Values.

Example — Non-initialized pointer error
#include <stdlib.h>

int* assign_pointer(int* prev)
{
    int j = 42;
    int* pi;

    if (prev == NULL) 
      {
        pi = (int*)malloc(sizeof(int));
        if (pi == NULL) return NULL;
      }

    *pi = j;                     //Noncompliant
    /* Defect: Writing to uninitialized pointer */

    return pi;
}

If prev is not NULL, the pointer pi is not assigned an address. However, pi is dereferenced on every execution paths, irrespective of whether prev is NULL or not.

Correction — Initialize Pointer on Every Execution Path

One possible correction is to assign an address to pi when prev is not NULL.

#include <stdlib.h>

int* assign_pointer(int* prev)
{
    int j = 42;
    int* pi;

    if (prev == NULL) 
       {
        pi = (int*)malloc(sizeof(int));
        if (pi == NULL) return NULL;
       } 
    /* Fix: Initialize pi in branches of if statement  */
    else 
        pi = prev;              
    

    *pi = j;

    return pi;
}
Issue

This issue occurs when a variable is not initialized before its value is read.

Risk

Unless a variable is explicitly initialized, the variable value is unpredictable. You cannot rely on the variable having a specific value.

Fix

The fix depends on the root cause of the defect. For instance, you assigned a value to the variable but the assignment is unreachable or you assigned a value to the variable in one of two branches of a conditional statement. Fix the unreachable code or missing assignment.

Often the result details (or source code tooltips in Polyspace as You Code) show a sequence of events that led to the defect. You can implement the fix on any event in the sequence. If the result details do not show this event history, you can search for previous references of variables relevant to the defect using right-click options in the source code and find related events. See also Interpret Bug Finder Results in Polyspace Desktop User Interface or Interpret Bug Finder Results in Polyspace Access Web Interface (Polyspace Access).

See examples of fixes below. It is a good practice to initialize a variable at declaration.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

Extend Checker

You can extend the checker in the following ways:

Example — Non-initialized variable error
int get_sensor_value(void)
{
    extern int getsensor(void);
    int command;
    int val;

    command = getsensor();
    if (command == 2) 
      {
        val = getsensor();
      }

    return val;               //Noncompliant
    /* Defect: val does not have a value if command is not 2 */
}

If command is not 2, the variable val is unassigned. In this case, the return value of function get_sensor_value is undetermined.

Correction — Initialize During Declaration

One possible correction is to initialize val during declaration so that the initialization is not bypassed on some execution paths.

int get_sensor_value(void)
{
    extern int getsensor(void);
    int command;
    /* Fix: Initialize val */
    int val=0;

    command = getsensor();
    if (command == 2) 
      {
        val = getsensor();
      }

    return val;              
 }

val is assigned an initial value of 0. When command is not equal to 2, the function get_sensor_value returns this value.

Check Information

Category: Others

Version History

Introduced in R2024a