<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho <<a href="mailto:Manuel.Coutinho@edisoft.pt">Manuel.Coutinho@edisoft.pt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
It has been some time since my last email. Hope you are doing well!<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 (<a href="https://docs.rtems.org/branches/master/eng/coding.html" rel="noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/coding.html</a>) 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.<br>
<br>
We have some preferences:<br>
 - have only automatically verified tools (to reduce the amount of manual verifications to a minimum)<br>
 - use preferentially open-source tools<br>
 - use at most 2 tools<br>
 - 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.<br>
<br>
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.<br>
<br>
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. <br>
Please keep in mind that some tools, while they are good to use, don't give a well-defined ruleset. <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The MISRA C coding guide is not freely available. This is a barrier to open discussion about the merit to adopting the rules. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">It is likely close to time to discuss if we will use an annotation like spdx to denote files which have artifacts.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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".<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">What's the other tool?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
After we define this rule set, we suggest that the current standard (in <a href="https://docs.rtems.org/branches/master/eng/coding.html" rel="noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/coding.html</a>) 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.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">And some of those are verifiable. Let's start with those </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kind regards,<br>
Manuel Coutinho<br>
Technical Manager<br>
Aeronautics & Space Systems <a href="mailto:manuel.coutinho@edisoft.pt" target="_blank" rel="noreferrer">manuel.coutinho@edisoft.pt</a> <br>
Tel: +351 212 945 906<br>
Fax: +351 212 945 999<br>
Rua Calvet Magalhães, 245<br>
2770-153 Paço de Arcos · Portugal<br>
<a href="http://www.edisoft.pt" rel="noreferrer noreferrer" target="_blank">www.edisoft.pt</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>