On Thu, Mar 23, 2023 at 11:09 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 23.03.23 17:03, Joel Sherrill wrote: > > > > On Thu, Mar 23, 2023 at 10:40 AM Sebastian Huber > > <sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > Close #4863. > > --- > > cpukit/include/rtems/score/objectimpl.h | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/cpukit/include/rtems/score/objectimpl.h > > b/cpukit/include/rtems/score/objectimpl.h > > index c58957ccb5..a1a87b5ccb 100644 > > --- a/cpukit/include/rtems/score/objectimpl.h > > +++ b/cpukit/include/rtems/score/objectimpl.h > > @@ -542,9 +542,7 @@ static inline bool _Objects_Is_api_valid( > > uint32_t the_api > > ) > > { > > - if ( !the_api || the_api > OBJECTS_APIS_LAST ) > > - return false; > > - return true; > > + return ( 1 <= the_api && the_api <= OBJECTS_APIS_LAST ); > > } > > > > > > I'd really prefer we avoid compound logical expressions since it > > becomes something that needs MCDC analysis at higher levels > > of verification/qualification. > > How does this simplify MC/DC analysis? The truth table doesn't change if > I replace a short-circuit boolean expression with if + return. > gcov cannot directly do mcdc analysis but using simple expressions avoids the introduction of those cases. So gcov reports can be equivalent of an expensive MCDC analysis tool. I'm at the FSW this week and one of the NASA Johnson people shared information on an open source tool and way to use gcov where you are guaranteed to have gcov reports cover this. I'm going to experiment with this when I get home. If it is as easy as it sounds, I'll write up something on the technique and we can discuss if we want to apply this to RTEMS. I think we do since it would allow us to use gcov to ensure we do MCDC level analysis as required by the highest level of all the safety standards I know. > > > > > Please rewrite using simple logical expressions even if it means > > two exit paths at the source leve. It's the same machine code. > > Yes. > Thanks. > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel