"char" vs. "signed char" vs. "unsigned char" in rule 10.5

[andersl]

In C, there are three types of characters: "char", "signed char", and "unsigned char". (The representation of the type "char" is either signed or unsigned). Note that this makes characters different than the other integer types as, for example, "short" is a synonym for "signed short".

Rule 10.5 states "if the bitwise operators ~ and

[jbezem]

1. MISRA requires that you define your own types like "uint8_t", using built-in types without typedef is discouraged/forbidden. (Rule 6.3)
2. Type 'char' (plain) shall only be used for character values, the only allowed operations are assignment and (in)equality. (Rule 6.1)

Your case is in violation of Rule 6.1, so 10.5 is not the only violation. Rule 10.5 has not been designed for situations covering "plain char" underlying types.

HTH,

Johan

[andersl]

Thanks for the rely!

I just realized that I forgot to describe the background for the question. The company I represent develops compilers with a built-in Misra C checker. (I'm fully aware that you have to break a number of Misra rules to use plain char:s when performing arithmetical operations, still code like that is used.)

Concretely, in the following program, our tools currently issues a violation for rule 10.3 for both functions, but only the first is considered a violation to rule 10.5. However, the problem that the rule tries to catch is the same for both functions.

typedef unsigned short UINT16_T;
typedef unsigned char UINT8_T;
typedef char CHAR_T;

UINT16_T from_unsigned_char(UINT8_T a);
UINT16_T from_plain_char(CHAR_T a);

UINT16_T from_unsigned_char(UINT8_T a)
{
return ~a;
}

UINT16_T from_plain_char(CHAR_T a)
{
return ~a;
}

So the question still stands: Should/could we issue a Misra C violation for rule 10.5?

-- Anders

[Lundin]

MISRA did state somewhere on these boards that 10.5 should be regarded as an exception to 10.3.

My static analyzer (LDRA) gives warning for violation of 10.5 in the first case but for 10.1 in the second case.
This seems like a sensible solution, as 10.1 and 10.5 overlap. As long as the tool gives some kind of warning...

[misra-c]

The MISRA C working group considers this to be a violation of Rule 6.1.

Rule 10.5 only applies to unsigned char and unsigned short. It does not apply to plain char.

Rule 12.8 would apply if bitwise operators were applied to a signed type.