<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Andrei,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you for your feedback.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think that we have document the deviations if “RTEMS” wants to be “MISRA compliant”.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Manuel<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Andrei Chichak [mailto:andrei@chichak.ca] <br><b>Sent:</b> terça-feira, 30 de julho de 2019 07:19<br><b>To:</b> Joel Sherrill<br><b>Cc:</b> Manuel Coutinho; rtems-devel@rtems.org<br><b>Subject:</b> Re: RTEMS Software Coding Standard<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Andrei (hanging around in the wings)<o:p></o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><div><p class=MsoNormal>On Jul 24, 2019, at 5:10 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p><div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>On Wed, Jul 24, 2019, 3:59 AM Manuel Coutinho <<a href="mailto:Manuel.Coutinho@edisoft.pt">Manuel.Coutinho@edisoft.pt</a>> wrote:<o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>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" 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.<span class=apple-converted-space> </span><br>Please keep in mind that some tools, while they are good to use, don't give a well-defined ruleset.<span class=apple-converted-space> </span><o:p></o:p></span></p></blockquote></div></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>The MISRA C coding guide is not freely available. This is a barrier to open discussion about the merit to adopting the rules. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>It is likely close to time to discuss if we will use an annotation like spdx to denote files which have artifacts.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>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".<o:p></o:p></span></p></blockquote></div></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>What's the other tool?<o:p></o:p></span></p></div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><br>After we define this rule set, we suggest that the current standard (in<span class=apple-converted-space> </span><a href="https://docs.rtems.org/branches/master/eng/coding.html" 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.<o:p></o:p></span></p></blockquote></div></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>And some of those are verifiable. Let's start with those <o:p></o:p></span></p></div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><br>Kind regards,<br>Manuel Coutinho<br>Technical Manager<br>Aeronautics & Space Systems<span class=apple-converted-space> </span><a href="mailto:manuel.coutinho@edisoft.pt" target="_blank">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/" target="_blank">www.edisoft.pt</a><br>_______________________________________________<br>devel mailing list<br><a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br><a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><o:p></o:p></span></p></blockquote></div></div></div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>_______________________________________________<br>devel mailing list<br></span><a href="mailto:devel@rtems.org"><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>devel@rtems.org</span></a><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'><br></span><a href="http://lists.rtems.org/mailman/listinfo/devel"><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif"'>http://lists.rtems.org/mailman/listinfo/devel</span></a><o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>