RTEMS Software Coding Standard

Tue Jul 30 10:19:34 UTC 2019

Hi Andrei,

Thank you for your feedback.

I think that we have document the deviations if “RTEMS” wants to be “MISRA compliant”.

For the ESA pre-qualification project it is not required that RTEMS is “MISRA compliant”, but may be it could be. In this case I think you are right, to be MIRSA2012 compliant  all mandatory rules must be implemented and all required rules and directives violations must be documented and explained.

Regards,
Manuel

From: Andrei Chichak [mailto:andrei at chichak.ca]
Sent: terça-feira, 30 de julho de 2019 07:19
To: Joel Sherrill
Cc: Manuel Coutinho; rtems-devel at rtems.org
Subject: Re: RTEMS Software Coding Standard

If I may, remember that MISRA has the organizations go through the rules, determine which ones they will adopt, and document deviations for the others.

If Sebastian feels strongly that one function exit is never going to happen, and the rest of the development group agrees, document it fully and hand it in. But look at the rationale, there may be something there to learn or ignore.

If Joel feels that identifiers that have 32 identical leading characters are fine because the rule is archaic, document it fully and hand it in.

Also, I believe that MISRA requires the use of C89, definitely the first version did. I’d have to check my copy of the later version to see if it had been revved to C99. You’d need a deviation for the version you plan to use.

Andrei (hanging around in the wings)

On Jul 24, 2019, at 5:10 AM, Joel Sherrill <joel at rtems.org<mailto:joel at rtems.org>> wrote:

On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho <Manuel.Coutinho at edisoft.pt<mailto: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<mailto: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<http://www.edisoft.pt/>
_______________________________________________
devel mailing list
devel at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel at rtems.org<mailto: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/20190730/e7e7eb7a/attachment-0002.html>