Page History

...

In most cases, compilers warn about uninitialized variables. These warnings should be resolved as recommended by MSC00-AC. Compile cleanly at high warning levels.

Additionally, memory allocated by functions such as malloc() should not be used before being initialized as its contents are indeterminate.

...

Noncompliant Code Example

In this non-compliant noncompliant code example, the set_flag() function is intended to set the variable sign to 1 if number is positive and -1 if number is negative. However, the programmer neglected to account for number being 0. If number is 0, then sign remains uninitialized. Because sign is uninitialized, and again assuming that the architecture makes use of a program stack, it uses whatever value is at that location in the program stack. This may lead to unexpected or otherwise incorrect program behavior.

...

This defect results from a failure to consider all possible data states (see MSC01-AC. Strive for logical completeness). Once the problem is identified, it can be trivially repaired by accounting for the possibility that number can be equal to 0.

void set_flag(int number, int *sign_flag) {
  if (sign_flag == NULL) {
    return;
  }
  if (number >= 0) { /* account for number being 0 */
    *sign_flag = 1;
  } else {
    assert(number < 0);
    *sign_flag = -1;
  }
}

void func(int number) {
  int sign;

  set_flag(number, &sign);
  /* use sign */ 
}

...

Noncompliant Code Example

In this non-compliantnoncompliant code example, the programmer mistakenly fails to set the local variable {{error_log}} to the {{msg}} argument in the {{report_error()}} function \[[mercy 06|AA. C References#mercy 06]\].  Because {{error_log}} has not been initialized, on architectures making use of a program stack, it assumes the value already on the stack at this location, which is a pointer to the stack memory allocated to the {{password}} array.  The {{sprintf()}} call copies data in {{password}} until a null byte is reached. If the length of the string stored in the {{password}} array is greater than the size of the {{buffer}} array, then a buffer overflow occurs.

#include <stdio.h>
#include <ctype.h>
#include <string.h>

int do_auth(void) {
  char *username;
  char *password;

  /* Get username and password from user, return -1 if invalid */
}

void report_error(const char const *msg) {
  const char const *error_log;
  char buffer[24];

  sprintf(buffer, "Error: %s", error_log);
  printf("%s\n", buffer);
}

int main(void) {
  if (do_auth() == -1) {
    report_error("Unable to login");
  }
  return 0;
}

...

Noncompliant Code Example

In this non-compliant noncompliant code example, the report_error() function has been modified so that error_log is properly initialized.

void report_error(const char const *msg) {
  const char const *error_log = msg;
  char buffer[24];

  sprintf(buffer, "Error: %s", error_log);

  printf("%s\n", buffer);
}

...

enum {max_buffer = 24};

void report_error(const char const *msg) {
  const char const *error_log = msg;
  char buffer[max_buffer];

  snprintf(buffer, sizeof( buffer), "Error: %s", error_log);
  printf("%s\n", buffer);
}

...

void report_error(const char const *msg) {
  printf("Error: %s\n", msg);
}

...

The LDRA tool suite V 7.6.0 is able to can detect violations of this rule.

Fortify SCA Version 5.0 is able to can detect violations of this rule, but will return false positives if the initialization was done in another function.

Compass/ROSE automatically detects simple violations of this rule, although it may return some false positives. It may not catch more complex violations, such as initialization within functions taking arguments to uninitialized variables. It does catch the second non-compliant noncompliant code example, and can be extended to catch the first as well.

...