MISRA Discussion Forums - 4.7 Standard conversions

Rule 7.0.2: Why the requirement for 'explicit' conversion operator?

Thu, 27 Nov 2025 09:04:13 +0000

Rule 7.0.2 has exceptions for "a class type having an explicit operator bool."

Question: why does the conversion operator have to be 'explicit' for the exception to apply? Even if the conversion operator is implicit, clearly the class was designed to be convertible to bool. This requirement seems therefore excessive.

I'm thinking for example about std::bitset::operator[] which returns a proxy object convertible to bool. However since the conversion operator is not explicit (as specified in the C++ standard), then even performing an explicit cast to bool from the proxy object violates Rule 7.0.2.

Note: I am aware that the 'const' version of std::bitset::operator[] should return a 'bool' directly, but some implementations return the proxy object also here, so the conversion is still necessary.

Rule 7.0.5, example non-compliant with 7.0.6?

Thu, 17 Apr 2025 12:10:54 +0000

Rule 7.0.5 presents this example:

Code:
u8a += static_cast< uint32_t >( u8b ) // Compliant - u8a -> unsigned int

Yes, compliant with 7.0.5. But this code then violates 7.0.6, since there is an implicit narrowing conversion from uint32_t to uint8_t in the assignment, right?

Code:
u8a = (uint32_t)(u8a) + (uint32_t)(u8b);

So, how are we supposed to write this type of code? Like this?

Code:
u8a = static_cast(static_cast(u8a) + static_cast(u8b));

Does that really make the code safer?

Rule 7.0.6 - why the requirement of "id-expression"?

Thu, 09 Jan 2025 08:43:25 +0000

Rule 7.0.6 provides the following amplification for assigning numerical types:

2. The source and target shall have types of the same type category, signedness, the source size
shall be smaller than the target size, and the source shall be an id-expression;

Question: why must the source be an "id-expression"?

Consider this example:

Code:
struct Foo

{

  float bar;

};

float a;

Foo f;

double d1 = a;      // Compliant, since it's an id-expression

double d2 = f.bar;  // Non-compliant, since it's NOT an id-expression (it's a member-expression)

This is inconsistent. The fact that we are using a member-expression instead of an id-expression does not have any impact on how the conversion is made, it's equally safe.

Would it make sense to remove the "id-expression" part of the rule? Otherwise, can you elaborate on why is it needed, what problems does it guard against?

Thanks!

rule 7.0.5: clarification regarding scope / expressions vs full expressions

Mon, 06 Jan 2025 11:56:20 +0000

Hi,

as I understand it right now, rule 7.0.5 is very strict and often prevents unsigned integer types smaller than int from being used in a MISRA-compliant way. For example, take

Code:
const uint8_t cu8a = 0;

const uint16_t cu16a = 0;

static_assert(cu8a == cu16a);

Here, integral promotions happen on both the lhs and rhs of the == operator. Both are implicitly converted to int, thus changing from unsigned to signed, causing a violation to MisraC++ 2023 Rule 7.0.5.

But does Rule 7.0.5 even apply in this case? The rule is supposed to apply to "all expressions (including sub-expressions) of _numeric_ type". "cu8a == cu16a" is of type bool, so the rule does not apply to the full expression. However, the expressions on the LHS and RHS individually are of a numerical type and consist of the implicit "(int)cu8a" / "(int)cu16a.

The rule also states "For the usual arithmetic conversions, only the final type of an operand is considered." Which could suggest a restriction for operators that return integral types (otherwise the expression itself would not be of integral type and not considered at all).

The same case could be made with an implicit cast to bool, eg taking the sum or difference of cu8a and cu16a.

How exactly is the rule supposed to be scoped and what expressions / operands does it consider?

Rule 7.0.2: Unclear/questionable rationale

Fri, 06 Dec 2024 09:29:45 +0000

Hi,

Rule 7.0.2 bans any type of conversion to bool (implicit or explicit) anywhere in the code (with some exceptions). The rationale says:

"However, this interpretation may not be appropriate for APIs, such as POSIX, that do not use Boolean return values."

This sounds strange, why should modern C++17 code (that may not use C-style POSIX functions at all) be limited by this?

Could you show an example code that highlights how this is a problem and leads to unexpected behavior? For example, how is this code unsafe/can lead to unexpected results?

Code:
bool b1 = static_cast< bool >( 4 );  // Non-compliant

Conversion from fundamental types to bool is well-defined behavior as per [conv.bool]:

"A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true."

Thanks!

Rule 7.0.4 - exception for binary bitwise operators and constant operands?

Thu, 05 Dec 2024 13:06:01 +0000

Hi,

My interpretation of Rule 7.0.4 is that it does not allow this type of code:

Code:
my_function(FLAG_A | FLAG_B | FLAG_C);

This is quite frequent when interfacing with third-party as well as POSIX C APIs. Casting each argument to unsigned type would go in detriment of readability.

Would it make sense to add an exception for signed constants?

Thanks!

Rule 7.0.2: operator const char *()

Fri, 11 Oct 2024 12:33:28 +0000

Hello,

Rule 7.0.2 has an exception for converting pointer to bool, and requires an explicit operator bool() for classes. But what if a class, let's say a wrapper class for strings, provides an operator const char *? Consider the following example:

Code:
class C

{

public:

    operator const char *() const;

};

void f(C c)

{

    if (c); // C is converted twice: C -> const char * -> bool

}

Shall the commented line be considered compliant with this rule (because each of the conversion steps by itself is compliant), or not (because as a whole it is the conversion of a class to bool without using an explicit operator bool)?

Rule 7.0.4 - example not compliant with 7.0.5?

Thu, 12 Sep 2024 12:56:09 +0000

Hi,

Rule 7.0.4 provides this example as compliant, and does not violate other rules (like other examples)

Code:
static_cast< uint16_t >( u8 + u16 ) << 2;  // Compliant

Why doesn't this example violate 7.0.5? Bit shift applied on uint16_t will cause integral promotion from uint16_t to int, thus violating 7.0.5, or?

Thanks!

Rule R7.0.1 converting constructor question

Thu, 22 Aug 2024 19:58:16 +0000

Hello,

Rule 7.0.1 allows for an explicit cast from bool to T when T has a converting constructor with a parameter of type bool. The example for the rule shows:

struct A
{
explicit A ( bool );
};

A anA { true }; // Compliant - constructor

Yet, C++ requires a converting constructor to be non-explicit.

I'm not sure what the intent is, but perhaps the rule should allow for an explicit cast from B to T when T has an explicit constructor that takes a single parameter, a parameter of (possibly const-qualified) type bool.

Please advise. Thank you.

Rule 7.0.5 Example potential typo

Thu, 21 Mar 2024 13:57:02 +0000

```c
constexpr int32_t fn( int32_t i )
{
return i * i;
}

u8 + fn( 10 ) // Compliant by exception #1
```

Is u8 a typo? Reasonable one might be 'u32 + fn(10)'?

u8 << 2 is non-compliant, so should u8 + f(10), this should be a typo.