<div dir="ltr"> Hi<div><br></div><div>I have run Coverity Scan against the master using GCC 9. I am including a list of the number of issues reported by file.  First let me be clear that there is only one issue reported for the "core" of RTEMS (e.g. score, rtems, posix, sapi, libcsupport). These have not been extensively analysed but my impression is that most of the outstanding 125 issues are minor or in non-critical third-party code but fixing or deciding not to analyse them is a team decision. </div><div><br></div><div>I know the nature of Coverity Scan's web interface makes it painful to create tickets from. But I would like to somehow get the number of issues down. </div><div><br></div><div>There are about 20 issues on third-party code in cpukit. I have mentioned not running the analysis on all files from third-parties since we likely do not want to touch them. This decision alone would likely eliminate many of the issues. This is things like fdt, sha, and some shell code.</div><div><br></div><div>Fixing printf specifier issues flagged would eliminate about 25 issues. These need to be fixed.</div><div><br></div><div>grlib has 25-30 issues flagged. Do we include it in the analysis? </div><div><br></div><div>Some issues are in other SPARC/Leon3 BSP specific code. Do we analyse any BSP code? I can see saying the RTEMS Project analysis focuses on cpukit/ source that originated inside the project. But we have to make that decision as a team.</div><div><br></div><div>We would need to write up something to describe our decision making process on whatever we decide. </div><div><br></div><div>Our issue count is higher than I would like and many of these have lingered for a long time because no one is focusing on any issue outside the core critical code. Making a few decisions here could help. </div><div><br></div><div>--joel</div><div><br></div><div><br></div><div><br></div><div><br></div></div>