Rule 6-6-5 A function shall have a single point of exit at the end of function.

[Renan Lavarec]

Hello,

We are interested about id 0000023 but in C++.

We would like to be MISRA compatible.
But forbid multiple return in some case make the code less understandable.
Further more with the use of RAII, it is pretty safe to have multiple return inside a function.
This rule inherited from C where multiple return is highly unsafe is about to evolve in new version of MISRA C++ ?
If not, this is a "Required" rules, could it be added to a "deviation permits" ?


Example:
If we transform this code using "early return pattern" method which is not MISRA on rule 6-6-5.

Code:

int CheckIsOk()
{

if (currentObject == NULL)
{
    return E_ERR_1;
}
if (!IsClassValid(id))
{
    return E_ERR_2;
}

currentObject->test();

return E_OK;
}

into MISRA

Code:

int CheckIsOk()
{
int err = E_OK;
if (err == E_OK && currentObject == NULL)
{
    err = E_ERR_1;
}
if (err == E_OK && !IsClassValid(id))
{
    err = E_ERR_2;
}

currentObject->test(); // Developer miss to add "err == E_OK && "


return err;
}

If you miss to add a test somewhere like for testing "again" currentObject before to use it, you'll get a possible crash....
It increase complexity of code and make it unsecured.
Readability is something very important to get trusty code.

You can also transform it to another form

Code:

int CheckIsOk()
{
    int err = E_OK;
    if (currentObject)
    {
        if (IsClassValid(id))
        {
            currentObject->test();
        }
        else
        {
            err = E_ERR_2;
        }
    }
    else
    {
        err = E_ERR_1;
    }

    // "Difficulties" to add code here
    if( err == E_OK)
    {
        // Do something
    }

    return err;
}

But the readability is less good than "early return pattern", because you "jump" from "if" to "if" and the last part to execute some code is subject to errors (or after any else), if no test are added before the return statement to test the error state.


ps:
In MISRA 2008 document chapter 6-6-5, there is a synthax mistake on fn3, there is missing {}

[mishak]

Yes, this rule is a bit of a pain to live with at times. Unfortunately, functional safety standards (i.e. 61508 and derivatives) require that functions have a single point of exit - the rule is there to support that objective.

Personally, I see no issue with using a deviation supported with a "Reason" of code-quality.

It's worth noting that MISRA C:2012 has reduced the enforcement level of this rule to "Advisory", which makes it easier to manage as it could be set to "Disapplied" when using MISRA Compliance:2016.

There is also another compliant coding pattern that can be used which avoids the risk of failing to detect an error and that has better readability:

Code:

int CheckIsOk()
{
  int err = E_UNEXPECTED;
  
  if ( currentObject == NULL )
  {
    err = E_ERR_1;
  }
  else if ( !IsClassValid( id ) )
  {
    err = E_ERR_2;
  }
  else
  {
    currentObject->test();
    err = E_OK;
  }
  
  return err;
}

[misra cpp]

We agree with mishak, the single point of exit from a function is a requirement of ISO/IEC 61508. Indeed, it is the only specific design requirement it places on code, and as you point out, arguably it can make code worse.

Your comment about 6-6-5 is incorrect - this is legal code. It’s called a function-try-block, and doesn't require brackets around the try..catch statements