Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Software vulnerabilities can result when a programmer fails to consider all possible data states.

Noncompliant Code Example (

...

if Chain)

This noncompliant code example fails to test for conditions where a is neither b nor c. This behavior may be the correct behavior in this case, but failure to account for all the values of a can result in logic errors if a unexpectedly assumes a different value.

Code Block
bgColor#FFCCCC
langc

if (a == b) {
  /* ... */
}
else if (a == c) {
  /* ... */
}

Compliant Solution (

...

if Chain)

This compliant solution explicitly checks for the unexpected condition and handles it appropriately.:

Code Block
bgColor#ccccff
langc

if (a == b) {
  /* ... */
}
else if (a == c) {
  /* ... */
}
else {
  /* handleHandle error condition */
}

Noncompliant Code Example (

...

switch)

The following This noncompliant code example fails to consider all possible cases. Failure to account for all valid values of type Color will result in a logic error. Since Because valid values of an enumerated type include all those of its underlying integer type, unless enumeration constants have been provided for all those values, the default label is appropriate and necessary.

Code Block
bgColor#ffcccc
langc

typedef enum { Red, Green, Blue } Color;
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
  }
}

void g() {
  Color unknown = (Color)123;
  puts(f(unknown));
}

...

Microsoft Visual C++ .NET with /W4 does not warn when assigning an integer value to an enum type , or when the switch statement does not contain all possible values of the enumeration.

Compliant Solution (

...

switch)

The This compliant solution below takes care to provide the default label to handle all valid values of type Color:

Code Block
bgColor#ccccff
langc

typedef enum { Red, Green, Blue } Color;
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
    default: return "Unknown color";   /* necessaryNecessary */
  }
}

Note that adding a default case to a switch statement, even when all possible switch labels are specified, is exception an exception (MSC07-C-EX1) to recommendation MSC07-C. Detect and remove dead code.

An alternative compliant solution to the noncompliant code example above is to provide a return statement after the switch statement. Note, however, that this solution may not be appropriate in all situations.

Code Block
bgColor#ccccff
langc

typedef enum { Red, Green, Blue } Color;
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
  }
  return "Unknown color";   /* necessaryNecessary */
}

Historical Discussion

...

Originally, the consensus among those writing best practices was simply that each switch statement should have a default label. Eventually, emerging compilers and static analysis tools could verify that a switch on an enum type contained a case label for each enumeration value, but only if no default label existed. This led to a shift toward purposely leaving out the default label to allow static analysis. However, the resulting code was then vulnerable to enum variables being assigned int values outside the set of enum values.

These two practices have now been merged. A switch on an enum type should now contain a case label for each enum value , but should also contain a default label for safety. This is not more difficult to analyze staticallypractice does not add difficulty to static analysis.

Existing implementations are in transition, with some not yet analyzing switch statements with default labels. Developers must take extra care to check their own switch statements until the new practice becomes universal.

...

This noncompliant code example shows incomplete logic when converting dates. The code appeared in the Zune 30 media player, causing many players to lock up on December 30, 2008, at midnight PST. This noncompliant code example comes from the ConvertDays function in the real-time clock (RTC) routines for the MC13783 PMIC RTC. This noncompliant code sample It takes the number of days since January 1, 1980, and computes the correct year and number of days since January 1 of the correct year.

...

Code Block
bgColor#FFCCCC
langc

#define ORIGINYEAR 1980
UINT32 days = /* numberNumber of days since January 1, 1980 */
int year = ORIGINYEAR;
/* ... */

while (days > 365) {
  if (IsLeapYear(year)) {
    if (days > 366) {
      days -= 366;
      year += 1;
    }
  }
  else {
    days -= 365;
    year += 1;
  }
}

Compliant Solution (Zune 30)

This The following proposed rewrite is provided by at http://wwwwinjade.aeroxp.orgnet/2009/01/lesson-on-infinite-loops. The loop is guaranteed to exit, as  because days decreases for each iteration of the loop, unless the while condition fails , and the loop terminates.

Code Block
bgColor#ccccff
langc

#define ORIGINYEAR 1980
UINT32 days = /* inputInput parameter */
int year = ORIGINYEAR;
/* ... */

int daysThisYear = (IsLeapYear(year) ? 366 : 365);
while (days > daysThisYear) {
  days -= daysThisYear;
  year += 1;
  daysThisYear = (IsLeapYear(year) ? 366 : 365);
}

This compliant solution is for illustrative purposes and is not necessarily the solution implemented by Microsoft.

Risk Assessment

Failing to take into account all to account for all possibilities within a logic statement can lead to a corrupted running state, potentially resulting in unintentional information disclosure or abnormal termination.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MSC01-C

medium

Medium

probable

Probable

medium

Medium

P8

L2

Automated Detection

Tool

Version

Checker

Description

section
Astrée

LDRA tool suite

Include Page
LDRA
Astrée_V
LDRA
Astrée_V
Section

12 S

Section

Fully Implemented

Section

GCC

Include PageGCC_VGCC_V

 

Section

can detect some violations of this recommendation when the -Wswitch and -Wswitch-default flags are used

missing-else

switch-default

Partially checked
section
Compass/ROSE

 

 

Sectioncan


Can detect some violations of this recommendation. In particular, it flags switch statements that do not have a default clause. ROSE should

also

detect "fake switches

,

" as well (that is, a chain of if statements each checking the value of the same variable). These if statements should always end in an

"

else

"

clause, or they should mathematically cover every possibility. For instance, consider the following:

Code BlockbgColor#ccccff

  if (x > 0) {
	  /* ... */
  } else if (x < 0) {
    /* ... */
  } else if (x == 0) {
    /* ... */
  }
GCC
Include Page
GCC_V
GCC_V

Can detect some violations of this recommendation when the -Wswitch and -Wswitch-default flags are used

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C2000, C2002, C2004
section

Klocwork
 
Include Page
Klocwork_V
Klocwork_V
section

CWARN.EMPTY.LABEL 
LA_UNUSED
MISRA.IF.NO_ELSE
MISRA.SWITCH.WELL_FORMED.DEFAULT.2012
INFINITE_LOOP.GLOBAL
INFINITE_LOOP.LOCAL
INFINITE_LOOP.MACRO


LDRA tool suite
Include Page
LDRA_V
LDRA_V
48 S, 59 SFully implemented
Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V

CERT_C-MSC01-a
CERT_C-MSC01-b

All 'if...else-if' constructs shall be terminated with an 'else' clause

The final clause of a switch statement shall be the default clause

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

474, 744, 787, 9013

Partially supported

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rec. MSC01-C


Checks for missing case for switch condition (rule partially covered)

PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V517, V533, V534, V535, V556, V577, V590, V612, V695, V696, V719, V722, V747, V785, V786


RuleChecker
Include Page
RuleChecker_V
RuleChecker_V

missing-else

switch-default

Partially checked
SonarQube C/C++ Plugin
Include Page
SonarQube C/C++ Plugin_V
SonarQube C/C++ Plugin_V

ElseIfWithoutElse, SwitchWithoutDefault


Related Vulnerabilities

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

Related Guidelines

...

...

...

Switch

...

Statements and Static Analysis [CLL]

Bibliography

[Hatton 1995]Section 2.7.2, "Errors of

...

Omission and

...

Addition"
[Viega 2005]Section 5.2.17, "Failure to

...

Account for

...

Default Case in

...


...

Image Added Image Added Image Addedhttp://www.aeroxp.org/2009/01/lesson-on-infinite-loops] for analysis on the Zune 30 bugImage Removed      49. Miscellaneous (MSC)      MSC02-C. Avoid errors of omission