From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Kumar Gala
Sent: Friday, September 14, 2018 11:47 PM
To: Ceolin, Flavio <email@example.com>
Cc: firstname.lastname@example.org; Nashif, Anas <email@example.com>; Hibberd, Amber M <firstname.lastname@example.org>
Subject: Re: [Zephyr-devel] MISRA-C and Zephyr
On Sep 14, 2018, at 1:46 PM, Flavio Ceolin <email@example.com> wrote:
Recently I start working on Zephyr to be compliant with MISRA-C. I'd
like to give you a brief overview about MISRA-C and why this is
valuable to Zephyr.
MISRA-C is code guideline that define a subset of C that aims to make
embedded software safer, more secure and especially more portable. It
does it defining a set of guidelines that try to fill the gaps between
C specification and different implementations, it means things with
undefined behavior, unspecified behavior and things that the compiler
implementation is free to choose the behavior.
That's been said, every MISRA-C guideline is classified as rule or
directive. These rules and directives are classified in mandatory,
required or advisory. Mandatory means that the code must be compliant
with the guideline, required the code also must be compliant but it's
possible creating a deviation, advisory are recommendations and don't
need a formal deviation if ignored.
So, what about Zephyr ? Zephyr currently contains ~8k violations and
approximately half are either required or mandatory (~10). I'm filling
issues on github
contains (I hope) enough information about the problem and some
suggestions to approach them. I ask everybody to take a look on them
and give opinions. Some of them required collaboration of diverse
code-owners and developers.
To finish, why MISRA-C is valuable to Zephyr ?
- Following a standard helps with maintainability of the code.
- Process standards like ISO26262 and IEC61508 used to develop
critical products require that the code follows a code guideline
(ISO26262 explicitly recommends MISRA-C).
- Other proprietary RTOs are MISRA-C compliant, if we want to be more
with them, is good too.
- It'll help us spot problems bugs and avoid them. I've worked this
week in two guidelines that are not that intrusive and I found at
least three real bugs.
- We'll have less problems with different compilers, the mandatory
violations are regarding using specific gcc builtin functions.
If you have any questions regarding MISRA-C lets discuss it :)
Have you looked at various GitHub integration tools that might help check code for MISRA guidelines so we can automate such reviews in the future.
I think we need some automated way to check new PRs for issues before we invest a large amount of time fixing the code base, otherwise its just going to bitrot back to being non-MISRA compliant.