Welcome to the MISRA discussion forum

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?

Hi there. We are working on the automotive framework for programming of autonomous cars. Our framework has features that are very similar to those in Adaptive Autosar: https://www.autosar.org/standards/adaptive-platform/. We plan to certify this framework as a Safety Element Out of Context according to ISO 26262.

The framework is written in C++ and makes rather heavy use of constructs implemented in Standard Library (see below for the full list). Many C++ keywords like throw or lambdas use the C++ standard library. So removing the C++ standard library would lead to a dysfunctional compiler.

We are aware of 3 Standard Library implementations:
1. LLVM libc++: https://libcxx.llvm.org/docs/
2. GCC libstdc++: https://gcc.gnu.org/
3. Dinkumware: https://www.dinkumware.com/

Now the problem is that none of the above libraries are certified according to ISO 26262.

Questions:
1. **Are you aware of any ISO 26262 certified Standard Library? Or anybody that is working on it?**
2. **Would any of the above implementations qualify for a “proven in use” argument?**


Constructs in our framework used from the Standard Library:
```cpp
std::string
std::vector
std::map
std::unordered_map
std::allocator
std::allocator_traits

std::shared_ptr
std::make_shared
std::unique_ptr
std::make_unique
std::weak_ptr

std::enable_shared_from_this

std::move

std::ostream
std::ostringstream

std::lock_guard
std::mutex
std::shared_future
std::thread::hardware_concurrency
std::this_thread::yield()

std::enable_if
std::false_type
std::is_same
std::declval

std::function
std::bind

std::chrono*

std::numeric_limits

std::shared_future

std::runtime_error
std::invalid_argument

std::int32_t
std::type_index
std::snprintf
```