MISRA Compliance:2016 now available

[david ward]

MISRA Compliance:2016 and the associated document MISRA C:2004 Permits are now available as free downloads from the "Resources" section of this Bulletin Board.

MISRA Compliance sets out a framework for claiming compliance with MISRA coding guidelines including guidance on a robust and structured process for the use of deviations. It includes a mechanism for establishing pre-approved "permits" to help streamline the deviation process. It supersedes the compliance, deviation and process requirements previously published in various MISRA coding guidelines.

MISRA C:2004 Permits presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2004 guidelines. It should be used in conjunction with MISRA Compliance:2016, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

[dg1980]

I have a question about chapter 6.4: if you develop in C++ (using MISRA C++ 2008) while simultaneously using third party libraries written in C (using MISRA C 2004) which standard do you apply?

[misra cpp]

MISRA C++:2008 system-wide analysis should be used to check all the code within the project when the library is supplied and used in source code form, as all of the code will be compiled using a C++ compiler. Note that any C code wrapped in “extern C” will always be compiled by the C++ compiler.

Things are more complicated when the library is to be used in binary form. In that case, the library code should be checked in isolation (by the third party) against MISRA C:2004 with the project code being checked against MISRA C++:2008. The library API headers will be included in C and C++ code and will therefore be checked against MISRA C and C++. It is possible that use of API headers within C++ code will result in MISRA C++ violations that need to be managed through the deviation process.

Note that a MISRA checker will not be able to detect system-wide violations existing due to conflicts between C and C++ code when the library is supplied in binary form – this issue exists for any project using library code in binary form, as discussed in section 6.3 of MISRA Compliance:2016.

[dg1980]

MISRA C++:2008 system-wide analysis should be used to check all the code within the project when the library is supplied and used in source code form, as all of the code will be compiled using a C++ compiler. Note that any C code wrapped in “extern C” will always be compiled by the C++ compiler.

Things are more complicated when the library is to be used in binary form. In that case, the library code should be checked in isolation (by the third party) against MISRA C:2004 with the project code being checked against MISRA C++:2008. The library API headers will be included in C and C++ code and will therefore be checked against MISRA C and C++. It is possible that use of API headers within C++ code will result in MISRA C++ violations that need to be managed through the deviation process.

Note that a MISRA checker will not be able to detect system-wide violations existing due to conflicts between C and C++ code when the library is supplied in binary form – this issue exists for any project using library code in binary form, as discussed in section 6.3 of MISRA Compliance:2016.

Thank you very much for replying.
Unfortunately, it is not that simple.
While we do have all libraries available in source code, our make system chooses a C compiler for .c modules and a C++ compiler for .cpp modules.
In addition, there are certain modules which were developed by a third party using MISRA C 2004 but which we are not allowed to change due to legal contracts.
Does that change anything from your point of view?
Thanks again.