Start here

Home
About Klocwork
What's new
Fixed issues
Release notes
Installation

Reference

C/C++ checkers
Java checkers
C# checkers
MISRA C 2004 checkers
MISRA C++ 2008 checkers
MISRA C 2012 checkers
MISRA C 2012 checkers with Amendment 1
Commands
Metrics
Troubleshooting
Reference

Product components

C/C++ Integration build analysis
Java Integration build analysis
Desktop analysis
Refactoring
Klocwork Static Code Analysis
Klocwork Code Review
Structure101
Tuning
Custom checkers

Coding environments

Visual Studio
Eclipse for C/C++
Eclipse for Java
IntelliJ IDEA
Other

Administration

Project configuration
Build configuration
Administration
Analysis performance
Server performance
Security/permissions
Licensing
Klocwork Static Code Analysis Web API
Klocwork Code Review Web API

Community

View help online
Visit RogueWave.com
Klocwork Support
Rogue Wave Videos

Legal

Legal information

MISRA.ETYPE.CATEGORY.DIFFERENT.2012

The operands of an operator in which the usual arithmetic conversions are performed do not have the same essential type category.

MISRA C 2012 Rule 10.4: Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category

C90 [Implementation 21], C99 [Implementation 3.6(4)]

Category: Required

Analysis: Decidable, Single Translation Unit

Applies to: C90, C99

Amplification

This rule applies to operators that are described in usual arithmetic conversions (see C90 Section 6.2.1.5, C99 Section 6.3.1.8). This includes all the binary operators, excluding the shift, logical &&, logical || and comma operators. In addition, the second and third operands of the ternary operator are covered by this rule.
Note: the increment and decrement operators are not covered by this rule.

Rationale

The C language allows the programmer considerable freedom and will permit conversions between different arithmetic types to be performed automatically. However, the use of these implicit conversions can lead to unintended results, with the potential for loss of value, sign or precision. Further details of concerns with the C type system can be found in Appendix C.

The use of stronger typing, as enforced by the MISRA essential type model, allows implicit conversions to be restricted to those that should then produce the answer expected by the developer.

Exception

The following are permitted to allow a common form of character manipulation to be used:
  1. The binary + and += operators may have one operand with essentially character type and the other operand with an essentially signed or essentially unsigned type;
  2. The binary - and -= operators may have a left-hand operand with essentially character type and a right-hand operand with an essentially signed or essentially unsigned type.

Example

enum enuma { A1, A2, A3 } ena;
enum enumb { B1, B2, B3 } enb;

The following are compliant as they have the same essential type category:

ena > A1
u8a + u16b

The following is compliant by exception 1:

cha += u8a

The following is non-compliant with this rule and also violates Rule 10.3:

s8a += u8a /* signed and unsigned */

The following are non-compliant:

u8b + 2      /* unsigned and signed         */
enb > A1     /* enum<enumb> and enum<enuma> */
ena == enb   /* enum<enuma> and enum<enumb> */
u8a += cha   /* unsigned and char           */