[PATCH] score: Simplify _Objects_Is_api_valid()

[Sebastian Huber]

On 23.03.23 17:46, Joel Sherrill wrote:
> 
> 
> On Thu, Mar 23, 2023 at 11:09 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at 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.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>      > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at 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.

If you just have a certain type of boolean expressions, then from branch 
coverage follows MC/DC coverage:

https://www.adacore.com/uploads/techPapers/Couverture_ERTS-2012.pdf

There is some ongoing work to add MC/DC coverage to gcov:

https://inbox.sourceware.org/gcc-patches/20221012101619.7221-1-jorgen.kvalsvik@woven-planet.global/T/

This approach works at the level of the CFG, so it doesn't matter which 
C level style you use.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at 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/