<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:11 PM Peter Dufault <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Sep 11, 2020, at 13:43 , Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> <br>
> <a href="https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify</a><br>
> <br>
<br>
I've been using "uncrustify" for a long time. There are regular updates and quick responses for clearly reported issues.<br>
<br>
The formatting specification is complicated, but that goes along with being so configurable.  There are formatting specification GUIs and helpers that I haven't used to assist with the generation of the formatting spec. See the bottom of the main "github" page for "uncrustify".<br>
<br>
Joel, when you were working with me the source code reformatting script we were using used "uncrustify" as the main reformatting engine.<br></blockquote><div><br></div><div>I didn't know since it was hidden. :) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I can not help with this much.  However, if I had time to do it, I think I'd do it this way:<br>
<br>
- Choose files that the RTEMS community RTEMS agrees are perfect examples of RTEMS coding as reference sources.  There should be a few and some should be large.<br>
- The "uncrustify" source includes sample configurations in its source code "/etc" directory.  Use a subset of the sample configurations to reformat the RTEMS reference sources.  For example, reformat to match FreeBSD, Linux kernel, K&R, etc coding styles and store them as test input files.<br>
- Run "uncrustify" with a proposed RTEMS configuration file on the hacked reference files and then "diff" them with the original.<br>
<br>
Ideally you would wind up with an RTEMS configuration with no diffs regardless of how you reformatted the input.<br></blockquote><div><br></div><div>This is a decent plan. There are at least 12 files over 400 lines in the cpukit (score, rtems, sapi, and libcsupport) that I would consider potential candidates for this. </div><div><br></div><div>This matches my idea of minimizing the delta between defined current style and what the tool supports. Then we can decide to bend to the tool or push for changes to the tool.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I know this would use the same tool that is being tested to create the input test files, but I think in this case it's OK due to how invasively "uncrustify" can be configured to reformat the code.  For example, it can probably strip "{" "}" on single lines in a conditional.<br></blockquote><div><br></div><div>I like dense code and will admit it. I don't like styles that spread braces onto separate lines so you end up with this:</div><div><br></div><div>if ()</div><div>{</div><div>...</div><div>}</div><div>else</div><div>{</div><div>}</div><div><br></div><div>But I have come to appreciate that single like if's with no braces can be viewed as issues in safety and security coding standards so I am willing to give that up and a tool will help fix those with low effort if we get a good match on the other rules.</div><div><br></div><div>FWIW I have also come to believe that anything other than a single logical test in a logical expression should be eliminated or at least avoided. I just came off a project where doing that gave us very high Statement Coverage and produced no cases where MC/DC coverage analysis had to be done. A tool can't rework compound logical expressions into a series of simple ones, but we may want to consider a style that discourages any logical expression that would require MC/DC analysis. This appears to be a decent discussion of the topics:</div><div><br></div><div><a href="https://people.eecs.ku.edu/~hossein/Teaching/Fa09/814/Lectures/structural-testing-mcdc-tut.pdf">https://people.eecs.ku.edu/~hossein/Teaching/Fa09/814/Lectures/structural-testing-mcdc-tut.pdf</a><br><br>Thanks Peter. This does appear to be the approach to narrowing down the settings and getting to where we can trust them.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div></div>