Welcome to the MISRA discussion forum

Rule 5-0-3 says "A cvalue expression shall not be implicitly converted to a different underlying type."

The rationale goes on to say "an expression defined as a cvalue shall not undergo further implicit conversions".

In the expression 's64 = s32 + s32', the addition is a cvalue expression of underlying type int32_t. It is being assigned to an object of type int64_t. The C++ standard says (regarding the assignment operator): "If the left operand is not of class type, the [align=right] expression is implicitly converted to the cv-unqualified type of the left operand".

Does this "implicit conversion to the type of the left operand" qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression 's64 == s32 + s32' the addition is a cvalue expression of underlying type int32_t. The C++ standard says (regarding the equality operator): "The usual arithmetic conversions are performed on operands of arithmetic or enumeration type", the result of which will be that "the
operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank". Additionally, MISRA C++ defines "underlying type conversions" and says they are "conceptual replacements for the usual arithmetic conversions". In this case, the "underlying type conversions" say: "... if both operands have integral type, the underlying type of the expression can be found using the following: ... the type of the result is that of the larger type". Whether the "usual arithmetic conversions" or the "underlying type conversions" are used, the result of the addition will be converted to int64_t.

Does the application of the usual arithmetic conversions and the ensuing implicit conversion to the larger type qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


In the expression '0L == s32 + s32' (where long is int64_t and 0L is signed char as established here) does the implicit conversion from the promotion of the addition expression to int64_t qualify as causing the cvalue expression to be "implicitly converted to a different underlying type"?


Note that these examples intend to use s32 and 64 to avoid the operands to the addition operator undergoing sub-int promotion, i.e. s32 is 32-bit int and s64 is 64-bit long.

Hi,

Just to clarify what seems to be a mistake in the implementation of the static analysis tool I use:
According to the rationale, I believe that this rule does not refer to the shift operators, but only to following 6 operators:
&
|
^
&=
|=
^=
Am I right about this?

Thanks,
Udi.

Hi.

Rules 10-3-3 Rationale has the following description.

Re-declaring a function as pure may not meet developer expectations.

What do the developers expect?
What does it mean that it does not meet the expectations of developers?

Rules 16-2-3 Rationale has the following description.

If this multiple inclusion leads to multiple or conflicting definitions,
then this can result in undefined or erroneous behaviour.

I understood that it would be a multiple definition.

However, I do not understand the case of conflicting definition.
What kind of cases are there?

What does it mean to be "tested in a meaningful manner"?

Is there any requirement on what is done once tested? For example, if there is no corrective action is it sufficient to just log the error?

Does returning the error to the caller qualify? In an API, the implementation of a API function may call subsequent functions that return an error. If only one such function is called then the only thing to do with the error is return it to the original caller.

err_t func1(void)
{
}

err_t func2(void)
{
return func1();
}

In our project, almost the entire code base running on the uC is a library exposed via an IPC link. All errors are just propagated back up and eventually sent back across the link to the caller.

Dear All,

I have read MISRA guidelines and tried to implement in my source code, After running in static code analysis tool it give me 10.8 violation for the below expression saying

" The value of a composite expression shall not be cast to a different essential type category or a wider essential type."

u16 param_val_u16 = 0U;

param_val_u16 = (u16)(brk_itbv_p_brk_hsd_isense.Voltage_Filtered_u32 / 50U);

Can anyone please try to justify what exactly it meant to make it compliant even if I did the intent explicit type casting of u16 to achieve the destination.

Thanks in advance,

Few questions about MISRA C++ Working Group and its membership:

1. What is the process of applying for the membership in the C++ Working Group for the company? What are the requirements for such membership ?
2. How often the working group meetings are taking place ?

Thanks
Vlad

The rule forbids conversion between function pointer types.
I believe that this rule should exempt a function retrieved with GetProcAddress / dlsym, as I believe this is not an undefined / unspecified behavior (or is it?).
It might make sense to add a requirement to review and document these cases.

As known, EN 50128:2011 standard asks for evidence that a tool failure might not impact the software safety. In particular, emphasis is placed upon tools that might generate outputs which can directly or indirectly contribute to the executable code (including data) of the safety-related system. Therefore compilers are the first to be assessed in this respect. In case of C language, regardless if certain evidence is available of a compiler full conformance with ISO/IEC 9899:1999 (C99) standard, I was wondering if, at least based on gathered experience, the source code full compliance with MISRA C:2012 makes the source code itself more "robust" against possible residual failures of the compiler. In other words, if it can be said that upon fully complying with MISRA C:2012, the largest part of current compilers does not exhibit failures.

I have a project with functions which architecturally belong to one file and have external linkage so that they can be called from other parts of the software. A code checker tool claims that if one of these functions is called only from one other file in the project, this is a rule 8.7 violation and that I should move the definition of the function to the file which calls it (which would mess up the functional partitioning). Is this really intended by rule 8.7?

The rationale of the rule says: “Similarly, reducing the visibility of a function by giving it internal linkage reduces the chance of it being called inadvertently.” So, I've interpreted this rule as "if you use a function only in the translation unit where it is defined, make it static". But for example library functions are intended to be called by anyone who needs them and cannot be called inadvertently.

Could you please clarify what the correct interpretation is?