Enumeration types in C map to integers. The normal expectation is that each enumeration type member is distinct. However, there are some non-obvious errors that are commonly made that cause multiple enumeration type members A C enumeration defines a type with a finite set of values represented by identifiers known as enumeration constants, or enumerators. An enumerator is a constant integer expression whose value is representable as an int. Although the language allows multiple enumerators of the same type to have the same value, it is a common expectation that all enumerators of the same type have distinct values. However, defining two or more enumerators of the same type to have the same value can lead to some nonobvious errors.
...
Noncompliant Code Example
In this non-compliant noncompliant code example, enumeration type members can be assigned explicit valuestwo enumerators of type Color are assigned explicit values. It may not be obvious to the programmer that yellow and indigo have been declared to be identical values (6), as are green and violet (7). Probably the least dangerous error that can result from such a definition is attempting to use the enumerators as labels of a switch statement. Because all labels in a switch statement are required to be unique, the following code violates this semantic constraint and is required to be diagnosed by a conforming compiler:
| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Color { red=4, orange, yellow, green, blue, indigo=6, violet }; |
It may not be obvious to the programmer (though it is fully specified in the language) that yellow and indigo have been declared to be identical values (6), as are green and violet (7).
Compliant Solution
Enumeration type declarations must either
const char* color_name(enum Color col) {
switch (col) {
case red: return "red";
case orange: return "orange";
case yellow: return "yellow";
case green: return "green";
case blue: return "blue";
case indigo: return "indigo"; /* Error: duplicate label (yellow) */
case violet: return "violet"; /* Error: duplicate label (green) */
}
}
|
Compliant Solution
To prevent the error discussed of the noncompliant code example, enumeration type declarations must take one of the following forms:
- Provide provide no explicit integer assignments, as in this example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Color enum { red, orange, yellow, green, blue, indigo, violet }; |
- assign Assign a value to the first member only (the rest are then sequential), as in this example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Color { red=4, orange, yellow, green, blue, indigo, violet }; |
- assign Assign a value to all members so any equivalence is explicit, as in this example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Color { red=4, orange=5, yellow=6, green=7, blue=8, indigo=6, violet=7 }; |
It is also advisable to provide a comment explaining why multiple enumeration type members are being assigned the same value so that future maintainers don't mistakenly do not mistakenly identify this form as an error.
Of these three options, providing no explicit integer assignments is the simplest and consequently the preferred approach unless the first enumerator must have a nonzero value.
Exceptions
| Anchor | ||||
|---|---|---|---|---|
|
INT09-C-EX1: In cases where defining an enumeration with two or more enumerators with the same value is intended, the constant expression used to define the value of the duplicate enumerator should reference the enumerator rather than the original enumerator's value. This practice makes the intent clear to both human readers of the code and automated code analysis tools that detect violations of this guideline and would diagnose them otherwise. Note, however, that it does not make it possible to use such enumerators in contexts where unique values are required (such as in a
switch statement, as discussed earlier).| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Color { red, orange, yellow, green, blue, indigo, violet=indigo };
|
Risk Assessment
Failing to ensure that constants within an enumeration have unique values can result in unexpected logic results.
Recommendation | Severity | Likelihood |
|---|
Detectable | Repairable | Priority | Level |
|---|---|---|---|
INT09- |
1 (low)
1 (unlikely)
3 (low)
P3
L3
Automated Detection
The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.
C | Low | Probable | Yes | No | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Astrée |
| enum-implicit-value | Fully checked | ||||||
| Axivion Bauhaus Suite |
| CertC-INT09 | |||||||
| CodeSonar |
| LANG.STRUCT.INIT.ENUM | Inconsistent Enumerator Initialization | ||||||
| Compass/ROSE | |||||||||
| CC2.INT09 | Fully implemented | |||||||
| Helix QAC |
| C0724 | |||||||
| Klocwork |
| MISRA.ENUM.IMPLICIT.VAL.NON_UNIQUE.2012 | |||||||
| LDRA tool suite |
| 85 S, 630 S | Fully implemented | ||||||
| Parasoft C/C++test |
| CERT_C-INT09-a | In an enumerator list, the "=" construct shall not be used to explicitly initialise members other than the first, unless all items are explicitly initialised | ||||||
| PC-lint Plus |
| 488, 9148 | Partially supported | ||||||
| Polyspace Bug Finder |
| CERT C: Rec. INT09-C | Checks for situations where enumeration constants map to same value (rec. fully covered) | ||||||
| RuleChecker |
| enum-implicit-value | Fully checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2.2, "Enumeration specifiers"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "CCB Enumerator issues"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 9.3 |
Related Guidelines
...
INT08-A. Verify that all integer values are in range 04. Integers (INT) INT10-A. Do not make assumptions about the sign of the remainder when using the % operator