RTEMS Software Coding Standard

[Joel Sherrill]

On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho <Manuel.Coutinho at edisoft.pt>
wrote:

> Hello all,
>
> It has been some time since my last email. Hope you are doing well!
>
> Some of you already know that Edisoft together with Embedded Brains (and
> some other institutions) are in a joint project to pre-qualify RTEMS
> according to the ESA (ECSS) standards.
>
> One of the items required is the Software Coding Standard and one of the
> goals of the project is to minimize (hopefully eliminate) any deviation
> from a pre-qualified version of RTEMS and the community RTEMS.
>
> To that end, we ask your ideas of how the RTEMS software coding standard
> should look like. We have looked at your current coding standard (
> https://docs.rtems.org/branches/master/eng/coding.html) and made a
> preliminary analysis to it (see table in attach). For an open-source
> project, these rules are very good. Unfortunately, from a pre-qualification
> point of view, there are not so many rules that are verifiable and even
> fewer that are automatically verifiable by a tool that we can use in the
> project.
>
> We have some preferences:
>  - have only automatically verified tools (to reduce the amount of manual
> verifications to a minimum)
>  - use preferentially open-source tools
>  - use at most 2 tools
>  - the tool(s) should have a "well-defined" rule set and output (e.g. XML,
> YAML, whatever) so that the qualification toolchain (another tool that we
> are developing) can interpret the output and re-format the output to sphinx.
>
> As a side note (please lets not focus on this now), after selecting the
> rules there could be some violations to the rule and still the
> pre-qualification be successful. For that, we just need to justify why the
> violation occurred (was not corrected) and why the code is correct.
>
> We believe a good starting point would be the MISRA rules since they are
> well defined, lots of tools use them, they can eliminate a lot of errors.
> But we welcome any other suggestion.
> Please keep in mind that some tools, while they are good to use, don't
> give a well-defined ruleset.
>

The MISRA C coding guide is not freely available. This is a barrier to open
discussion about the merit to adopting the rules.

I personally have not seen the entire rule set in a long time since I don't
own a copy. My recollection is that I am against some of the rules. For
example, I vaguely recall a rule about 32 character global symbol names and
I am strongly opposed to that rule. It reflects limits in long unused
object formats. And that's just one I remember as being odd.

Each rule or handful will have to be proposed for evaluation independent of
having a copy of MISRA. The way it is checked by a FLOSS tool and its value
will have to be established.

The use of any rules which are adopted will have to be restricted to
certain directories. We can't change the style or format of third party
code.

It is likely close to time to discuss if we will use an annotation like
spdx to denote files which have artifacts.


We have looked at cppcheck for some time and only now we found that there
> is a ruleset. You can get it by running "cppcheck --errorlist".
>

What's the other tool?

>
> After we define this rule set, we suggest that the current standard (in
> https://docs.rtems.org/branches/master/eng/coding.html) be more or less
> renamed to a "Coding guidelines" instead of "Rules" because some of them
> are not verifiable and we believe the community should keep on following
> them. And create a new coding standard with the rules that are selected.
>

And some of those are verifiable. Let's start with those

>
> Kind regards,
> Manuel Coutinho
> Technical Manager
> Aeronautics & Space Systems manuel.coutinho at edisoft.pt
> Tel: +351 212 945 906
> Fax: +351 212 945 999
> Rua Calvet Magalhães, 245
> 2770-153 Paço de Arcos · Portugal
> www.edisoft.pt
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190724/208a7933/attachment-0002.html>