On Fri, Jan 13, 2017 at 4:47 AM, Sebastian Huber <sebastian.huber@embedded- brains.de> wrote:
> On 13/01/17 09:48, Sebastian Huber wrote: > >> On 12/01/17 22:44, Joel Sherrill wrote: >> >>> I repeat that I would like to purge old tests that result in >>> conditionals in >>> source code we no longer need. So any HAVE_XXX that are a side >>> effect of transitioning newlib additions should be removed. >>> >> >> I removed three tests today which I added in the last two years or so. >> > > I removed a couple of more obsolete configure stuff. I am done for now. > > Thanks. It is a continuous battle of creep and push back. Without looking, I am sure you are right that __RTEMS_DO_NOT_ INLINE_THREAD_ENABLE_DISPATCH__ is no longer used but it did serve a purpose that may have been lost in all the rework. When doing coverage testing, inlining a method with one of more conditionals increases the cyclomatic complexity of the calling method and number of test cases required to do full coverage of all branch paths. That flag eliminated at least 250 paths to test in the generated code. With the rework, did anything get inlined lots of times that includes a conditional test? If so, then the calling method has hidden cyclomatic complexity and requires increased test cases for full coverage. I am pretty sure this is written down as advice in the coverage area but I have no idea how to turn it into good solid coding style/rules. The best I can formulate is: Inlining a method requires that it be fully tested in the context of each place it is called. Inlining complex methods with conditionals is undesirable from a coverage testing viewpoint. Try to inline only simple methods. --joel > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel