<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 1, 2020, 1:02 PM suyash singh <<a href="mailto:suyashsingh234@gmail.com">suyashsingh234@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is regarding the project I would like to work in <div><br><div><span style="color:rgb(0,0,0);font-family:Arial,Verdana,"Bitstream Vera Sans",Helvetica,sans-serif;letter-spacing:-0.018em">Improve Coverity Scan Integration</span><br></div><div><a href="https://devel.rtems.org/ticket/3710" target="_blank" rel="noreferrer">https://devel.rtems.org/ticket/3710</a><br></div><div><br></div><div><b>FIRST POINT-</b></div><div>I was thinking about implementing Coverity or clang analyzer as an offline analyzer. Would it be a suitable idea to make a separate repo just for testing purposes?</div><div>This "testing repository" will have the updated rtems code as well the analyzer in it. If possible this repo will be updated automatically from the main repo.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I would have to see how the clang analyser is run against the RTEMS source. My expectation would be that ultimately something would be added to rtems-tools to run the analysis process and generate reports.</div><div dir="auto"><br></div><div dir="auto">The reports could then be locally generated or run on an <a href="http://rtems.org">rtems.org</a> server for publication.</div><div dir="auto"><br></div><div dir="auto">I don't see needing a private RTEMS repository. This should be an rtems-tools project and you would only have a personal copy of that for the purposes of getting reviews. Usually patches just get submitted and you don't need a public facing repo at all.</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"><div dir="ltr"><div><div><br></div><div><b>SECOND POINT-</b></div><div>Using Travis CI for github. I have seen Travis CI checking the build of pull requests in other repos.</div><div>Also making a special coverity branch to trigger coverity scan</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Amar should comment on this. RTEMS.org is using buildbot.</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"><div dir="ltr"><div><div><br></div><div><b>THIRD POINT-</b></div><div>Enabling and testing MISRA rules.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Do you know of a free tool that checks Misra C rules? There are closed source products that do but I don't know of a FLOSS one.</div><div dir="auto"><br></div><div dir="auto">Assuming you have identified a free software tool to do the analysis, the impact and applicability of each rule to the RTEMS source base needs evaluation. I know some of the rules we agree with but others we will not want to adopt. For example, Misra defines a subset of C Library header files you can include. RTEMS will violate that regularly and intentionally.</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"><div dir="ltr"><div><div><br></div><div><b>FOURTH POINT- </b></div><div>Reducing false positives.</div><div>I have yet to figure out how to do this one. </div><div>I noticed a pattern where value overwrite errors are given for unused values. There is email thread about it with subject "<span style="color:rgb(32,33,36);font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-variant-ligatures:no-contextual">Coverity false positive pattern</span>"</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If the tool flags a pattern in code incorrectly, then it needs to be reported to the tool owner.</div><div dir="auto"><br></div><div dir="auto">If there is an intentional violation, then the code may have to be annotated with an explanation. Also documenting the allowed types of exceptions is a critical part of the software engineering side of this.</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"><div dir="ltr"><div><div><br></div><div><b>FIFTH POINT-</b></div><div>Solving reported issues by coverity.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is always good and as recent traffic on the mailing list has shown is often more difficult than at first glance.</div><div dir="auto"><br></div><div dir="auto">It is good work and appreciated. Just can't be measured by number of lines of code since you are usually fixing with a scalpel something subtle</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"><div dir="ltr"><div><div><br></div><div><br></div></div></div>
_______________________________________________<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>